idnits 2.17.1 draft-palet-v6ops-auto-trans-02.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1034. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1011. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1018. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1024. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 7) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages 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.) 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 (October 24, 2004) is 7122 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) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '1') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '2') (Obsoleted by RFC 8415) == Outdated reference: A later version (-11) exists of draft-ietf-v6ops-3gpp-analysis-10 == Outdated reference: A later version (-03) exists of draft-palet-v6ops-tun-auto-disc-01 == Outdated reference: A later version (-01) exists of draft-palet-v6ops-solution-tun-auto-disc-00 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-06 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Palet 2 Internet-Draft M. Diaz 3 Expires: April 24, 2005 Consulintel 4 M. Mackay 5 Lancaster University 6 October 24, 2004 8 Evaluation of IPv6 Auto-Transition Algorithm 9 draft-palet-v6ops-auto-trans-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 24, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This memo evaluates a method called "auto-transition" to ensure that 45 any device can obtain IPv6 connectivity at any time and whatever 46 network is attached to, even if such network is connected to Internet 47 only with IPv4 or already offers IPv6 but with poor performance. 49 The algorithm looks for the best possible transition mechanism 50 according to performance criteria information available as well as 51 the scenario where the device is located. 53 By implementing such auto-transition algorithm in either or both end 54 nodes or middle boxes (CPEs), users could always obtain IPv6 55 connectivity with no human intervention. 57 The document doesn't actually provides a complete solution, just an 58 evaluation of the problem and the requirements towards a future 59 documented solution. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Auto-Transition Overview . . . . . . . . . . . . . . . . . . . 3 65 3. Auto-Transition Requirements . . . . . . . . . . . . . . . . . 4 66 3.1 Selection of the proper transition mechanism . . . . . . . 5 67 3.2 Change of transition mechanism . . . . . . . . . . . . . . 7 68 3.3 New transition/tunneling mechanisms . . . . . . . . . . . 8 69 3.3.1 Layer 2 tunnels . . . . . . . . . . . . . . . . . . . 9 70 3.3.2 Layer 3 tunnels . . . . . . . . . . . . . . . . . . . 9 71 3.3.3 Layer 4 tunnels . . . . . . . . . . . . . . . . . . . 10 72 3.4 Discovery of the IPv6 End Point . . . . . . . . . . . . . 11 73 4. Nomadicity Considerations . . . . . . . . . . . . . . . . . . 12 74 5. Network Managed Transition . . . . . . . . . . . . . . . . . . 14 75 5.1 Policy Based Networks . . . . . . . . . . . . . . . . . . 15 76 5.2 Transitioning Server . . . . . . . . . . . . . . . . . . . 15 77 5.3 Host operation . . . . . . . . . . . . . . . . . . . . . . 16 78 5.4 Server operation . . . . . . . . . . . . . . . . . . . . . 18 79 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 84 9.2 Informative References . . . . . . . . . . . . . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 86 Intellectual Property and Copyright Statements . . . . . . . . 23 88 1. Introduction 90 This document evaluates a method called "auto-transition" to ensure 91 that any device can obtain IPv6 connectivity at any time and whatever 92 network is attached to, even if such network is connected to Internet 93 only with IPv4 or already offers IPv6 but with poor performance. 95 The main goal is to facilitate the IPv6 deployment in a seamless way 96 for devices, users and applications. Lots of devices and 97 applications around us will benefit obtaining IPv6 connectivity 98 everywhere: home automation, wearable devices, cars, PDAs, mobile 99 phones, peer-to-peer applications, remote control applications, etc. 100 IPv6 is suitable to solve the network requirements that those 101 devices/applications will need: addressing space, end-to-end secure 102 peer-to-peer communication, autoconfiguration features and so on. 104 IPv6 provides autoconfiguration features, enabling devices to work 105 according to the plug-and-play philosophy, that is with no manual 106 intervention. However they only can be applied once the device has 107 obtained IPv6 connectivity. On the other hand, while native IPv6 108 connectivity is not available everywhere, there is not a good 109 "auto-transition" algorithm to ensure this connectivity. 111 While devices are located in a native IPv6 environment, no manual 112 intervention is required, so non technical users can take advantage 113 of IPv6. However until all or most of the networks are IPv6 native, 114 we need to ensure that the same devices and users can use a 115 transition mechanism that ensures the best possible IPv6 116 connectivity, without any or low technical knowledge. Is not 117 acceptable require to the users to make manual configurations in 118 order to get the IPv6 connectivity, but is also possible that in the 119 early IPv6 deployment stage, administrators of small and medium size 120 networks (typically SOHO, SME), will not have the knowledge neither 121 the service from their ISPs. 123 The algorithm will deal with all the tasks required to configure 124 automatically the best IPv6 connectivity at anytime, in any network 125 scenario, which include native IPv6 connectivity detection and 126 transition mechanism selection if required. It can be implemented 127 either in stand-alone devices (hosts, PDA, etc.) or middle boxes like 128 CPE routers. 130 2. Auto-Transition Overview 132 When the device is attached to the network, either or both stateless 133 [1] or stateful autoconfiguration [2] mechanism are automatically 134 performed by default. The auto-transition algorithm then must check 135 if native IPv6 connectivity is available. Otherwise, the algorithm 136 should try to obtain IPv6 connectivity by using the best transition 137 mechanism according to the network where the devices is attached. 139 Later, the conditions of the network can change, even the user/device 140 can change the location while moving. Consequently the attachment 141 point to the network can be different and the previous transition 142 mechanism no longer be so well-performing or available at all. The 143 auto-transition algorithm has to monitor periodically the network 144 parameters (i.e. IPv4 address, loss, delays, etc.) in order to 145 detect those changes and decide if another transition mechanism 146 different to the one currently being used is convenient and provides 147 better performance to activate it. 149 All this process should be ideally automatic in order to avoid the 150 user to make any manual configuration. At the most, users only 151 should introduce some parameters by means of a wizard during the 152 installation process of the application that implements the 153 auto-transition algorithm, but once it is up and running, all the 154 tasks should be made by the system and no manual intervention 155 required. 157 This approach should be available at least in two kinds of platforms. 159 o End devices: Devices that do not intend to provide IPv6 160 connectivity to others. They are typically devices that would get 161 IPv6 connectivity by means of Router Advertisement if they were 162 attached to a native IPv6 scenario. Examples are hosts, PDAs, 163 mobile phones, cameras, home automation devices, white goods, 164 consumer electronics, etc. 166 o CPE devices: Devices that are located between two different 167 networks or networks segments. Typically routers, IPv4 NAT boxes, 168 etc. They should provide native IPv6 connectivity to the whole 169 network(s) located behind them by announcing an IPv6 prefix. With 170 this approach these kind of devices will be plug-and-play, so 171 users only have to attach them to the network and they will deal 172 with all the tasks to get IPv6 connectivity. A few applications 173 include home networks, hotels, hot-spots and so on. 175 3. Auto-Transition Requirements 177 The best IPv6 connectivity, in principle, is obviously the native one 178 if available, since it should not add extra delays in the 179 communication neither introduce more complexity to the networks. 180 Consequently the auto-transition algorithm first must check if IPv6 181 native connectivity is available. However it strongly depends on the 182 ISP support and can be expected that in the early IPv6 deployment 183 stage, only a few ISPs will provide it. 185 If native connectivity is not available the auto-transition algorithm 186 must choose the right transition mechanism to be used to ensure the 187 IPv6 connectivity. 189 A number of transition mechanisms have been defined already: Teredo, 190 TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, DSTM, etc. All of them work 191 when the host willing to get IPv6 connectivity has a public IPv4 192 address. Even some of them also work when the host is located behind 193 a NAT box that allows proto-41 forwarding [3]. However there are 194 other kinds of NAT boxes that prevent the existing transition 195 mechanisms to work, so there is a gap that could be filled with new 196 kind of solutions, possibly layer 2 or layer 4 tunnels. 198 The adequate selection of the proper transition mechanism is one of 199 the keys of the auto-transition concept. 201 The auto-transition goal is to facilitate an adequate transition to 202 IPv6. Towards that, it tries to automatically decide the most 203 optimal transition solution in every given scenario, which may be not 204 the perfect one. Actually implementing a perfect auto-transition 205 solution could be a very complicated, overloading and slow algorithm 206 (in addition to the delay in its specification and development); in 207 the case it happens, could bring us the paradigm that there is no 208 anymore an incentive for native IPv6 connectivity, which clearly is 209 in contradiction with the goals of this memo and in general the 210 (native) IPv6 deployment one. 212 3.1 Selection of the proper transition mechanism 214 A few scenarios with particular network requirements had been defined 215 already ([4], [5], [6], [7]). Not all the transition scenarios fit 216 in such network scenarios, as being evaluated at [8], which is trying 217 to make the best fit to each scenario. 219 The auto-transition algorithm may take into account not only the 220 results shown in [8], but also new conclusions, because it is also 221 possible a wider focus to select the best transition mechanism to be 222 used. What the end user always demands is the best performance on 223 the IPv6 connectivity, so it should be the main criteria to choose 224 the right transition mechanism. 226 Distance, delays, loss and bandwidth, are some of the related 227 parameters that could be used as metrics to be measured for knowing 228 the link performance. A device can present different values of such 229 metrics according to the transition mechanism that is being used even 230 when attached to the same network. 232 A combination of all the metrics could provide a fine evaluation of 233 the connection performance. However in order to make the mechanism 234 as simple as possible only delay and loss should be considered. 236 According to this philosophy the auto-transition algorithm could 237 operate by means of the following simple algorithm, where the 238 interactions are over the time: 240 loop 241 detect_scenario 242 if (native_IPv6_available and native_priority) 243 use_native_IPv6_connectivity 244 else 245 if (first_check or performance_check_allowed) 246 check_performance 247 use_best_mechanism 248 endif 249 endif 250 configure_connectivity 251 wait (link_check_timeout) 252 endloop 254 Figure 1: Simple Auto-transition algorithm 256 It is important to note what each task or parameter means: 258 o detect_scenario: This task deals with detecting the scenario where 259 the device willing to have IPv6 connectivity is located. It could 260 check if native IPv6 is available, if a public IPv4 address is 261 available, if a NAT is being used and (possibly) the type, if 262 there is a proxy or firewall, or if other protocols can be 263 operated. 265 o native_IPv6_available: Detects if native IPv6 is available. 267 o native_priority: Detects if native IPv6 has priority, for 268 instance, even in the case the performance is lower than the one 269 that could be obtained with alternative transition mechanism that 270 may be used (i.e. a native IPv6 network with is attached to a 271 non-native WAN link with IPv6 tunneled over IPv4 to and end-point 272 which offers a bad performance while there is a much better 273 TB/TS). This condition could be set by the OS, or even under user 274 or applications control. 276 o use_native_IPv6_connectivity: Configure the interface to use 277 native IPv6 connectivity, using stateless or stateful 278 autoconfiguration, upon their availability. 280 o first_check: Defines if this is the first time this check is being 281 done after an interface reset. 283 o performance_check_allowed: Defines if the performance of the 284 selected mechanism can be measured after selected, for instance, 285 to avoid traffic being generated in non-flat rate links (3GPP, 286 ISDN, ...). 288 o check_performance: According to the detected scenario, a number of 289 mechanisms could be used. This task checks the performance that 290 each of such transition mechanism provides, including native IPv6 291 if available, by measuring delays and losses. The mechanisms 292 subset will be defined by taking into account [8], but others 293 could be considered. 295 o use_best_mechanism: According to the measurement results, the best 296 mechanism is selected. 298 o configure_connectivity: Either native IPv6 connectivity or the 299 best available transition mechanism is configured. 301 o link_check_timeout: Once the IPv6 connectivity is obtained, the 302 auto-transition algorithm periodically monitors the link status. 303 The delay between consecutive checks is defined by this variable. 305 A possible list of mechanisms to be checked, ordered by preference 306 could be: 308 1. Native IPv6 Connectivity 310 2. TS with proto-41 ([3]) 312 3. TS with UDP 314 4. ISATAP 316 5. STEP 318 6. 6to4 320 7. Teredo 322 3.2 Change of transition mechanism 324 Change of transition mechanism refers to the task to abandon the 325 transition mechanism that is actually being used and start to use 326 another one that presents better performance. This is not an easy 327 task at all, since it involves at least two important issues: 329 1. To maintain the current IPv6 address. This is very important in 330 some situations, since otherwise applications with communications 331 opened will not work. Specially important is the case when the 332 auto-transition algorithm is implemented in border devices that 333 provide native IPv6 connectivity to the whole network. Either 334 the prefix network (i.e. RA), or the IPv6 addresses (i.e. 335 DHCPv6) that they provide, should try to keep the IPv6 addressing 336 parameters. If the auto-transition algorithm has to include the 337 possibility of changing the transition mechanism used without 338 discarding the current connection state, it is necessary to 339 define a method that solves this issue. MIPv6 concepts/solutions 340 could be applied and possibly also those related to multihoming. 342 2. User authentication without human intervention. The philosophy 343 of the auto-transition algorithm is that all the processes are 344 done automatically, with no human intervention. So, for 345 instance, if the device running the auto-transition algorithm 346 needs to contact with a TB different to one being already used, 347 and it requires user authentication, the process should be 348 transparent to the user. It could be based on parameters (login 349 and password) configured through the wizard during the 350 installation process. AAA mechanisms should be used. 352 In order to simplify the solution (i.e. not relying on MIPv6, 353 multihoming or others), it could be decided to keep using the 354 initially selected transition mechanism, even when not providing the 355 optimal connectivity, but instead ensuring that the IPv6 address is 356 stable. 358 In some situations it will be possible, even interesting, to keep 359 active multiple transition mechanisms, for optimization or other 360 purposes, even using some of them only in one direction, etc. TBD. 362 3.3 New transition/tunneling mechanisms 364 A number of devices do not allow tunnel-based transition mechanisms 365 to work properly. They are either NAT boxes, proxies or firewalls. 366 Even building IPv6 tunnels over UDP is not always possible since some 367 middle boxes do not forward those packets. 369 When this happens it is required that the auto-transition algorithm 370 uses a method that cannot be rejected by the middle box. However, is 371 important to realize that this may happen actually as a consequence 372 of a policy or security measure from the network, specially in 373 situations like enterprise networks. 375 The following sub-sections consider several alternatives. 377 3.3.1 Layer 2 tunnels 379 By using layer 2 encapsulating methods (L2TP [9], PPTP [10], PPPoE 380 [11]), the middle boxes barriers can be easily overcome since this 381 kind of protocols are very used when building layer 2 VPN. 382 Consequently, one of the following protocol stacks might be used. 384 +--------+ +--------+ 385 | IPv6 | | IPv6 | 386 +--------+ +--------+ 387 | PPP | | PPP | 388 +--------+ +--------+ +--------+ 389 | L2TP | | PPTP | | IPv6 | 390 +--------+ +--------+ +--------+ 391 | UDP | | TCP | | PPP | 392 +--------+ +--------+ +--------+ 393 | IPv4 | | IPv4 | | IPv4 | 394 +--------+ +--------+ +--------+ 396 L2TP tunnel PPTP tunnel PPPoE tunnel 398 Figure 2: Layer 2 tunnels 400 This kind of solution does not seem to be efficient due to the 401 following drawbacks: 403 o It requires that the TS is configured as VPN L2 server. 405 o Overloaded stack. IPv6 connection will have low performance. 407 o Complicated deployment and management due to the control plane for 408 L2TP and PPTP. 410 o Authentication is a must with PPP. It means added complexity. 412 3.3.2 Layer 3 tunnels 414 VPN's built by mean of layer 3 tunnels can be a solution to allow 415 IPv6 connections cross NAT boxes with no proto-41 forwarding 416 capabilities as well as proxies and firewalls. 418 +--------+ +--------+ 419 | IPv6 | | IPv6 | 420 +--------+ +--------+ +--------+ 421 | IPv4 | | IPv4 | | IPv6 | 422 +--------+ +--------+ +--------+ 423 | PPP | | IPsec | | IPv4 | 424 +--------+ +--------+ +--------+ 425 | IPv4 | | IPv4 | | IPv4 | 426 +--------+ +--------+ +--------+ 428 PPP-IPv4 IPsec IPv4-IPv4 430 Figure 3: Layer 3 tunnels 432 Compared to the Layer 2 tunnels, the layer 3 tunnels have the 433 following advantages: 435 o Less overloaded stacks. 437 o Tunnel management simpler. 439 o There are some implementations (VTun, cIPE, TINC). 441 However it also have important drawbacks: 443 o It requires that the TS is configured as VPN L2 server. 445 o Some NAT's could not support those. 447 3.3.3 Layer 4 tunnels 449 The last resort is to try to overcome the middle barriers by means of 450 the use of frequently used application protocols. There are two well 451 known possibilities that frequently will not create difficulties with 452 neither proxies nor firewalls: TLS/SSL, HTTP and SSH. Furthermore, 453 they neither have problems with NAT boxes. The protocol stack for 454 this solution is as follows: 456 +--------+ +--------+ +--------+ 457 | IPv6 | | IPv6 | | IPv6 | 458 +--------+ +--------+ +--------+ 459 | HTTPS | | HTTP | | SSH | 460 +--------+ +--------+ +--------+ 461 | TCP | | TCP | | TCP | 462 +--------+ +--------+ +--------+ 463 | IPv4 | | IPv4 | | IPv4 | 464 +--------+ +--------+ +--------+ 466 TLS/SSL tunnel HTTP tunnel SSH tunnel 468 Figure 4: Layer 4 tunnels 470 The main advantage of this approach is the simplicity for the 471 configuration of the tunnel. Furthermore the tunnels can be secured 472 by means of either SSL (using HTTPS instead of HTTP) or SSH. 474 Of course, this solutions are sub-optimal and consequently 475 discouraged. 477 According to the different alternatives, it sounds reasonable that 478 the better solution could be Layer 4-based tunnels, since it is 479 simpler than the others and always will work, but the performance 480 will not be optimal. Instead Layer 3 and Layer 2-based tunnels 481 should be taken into account in implementations of the 482 auto-transition algorithm in order to guarantee the IPv6 connectivity 483 by covering all the possible alternatives. 485 The usage of those new mechanisms is discouraged, unless there is no 486 other choice. In any case, the standardization of those different 487 tunnel options is out of the scope of this document. 489 3.4 Discovery of the IPv6 End Point 491 Devices running the auto-transition algorithm need to know where to 492 find the IPv6 (tunnel) end point or tunnel server (TS) that provides 493 them the IPv6 connectivity. If native IPv6 connectivity is provided 494 by the ISP and is being used used, then this TS will be obviously the 495 link end point and no further discovery work is required. This is 496 slightly more complex when a transition mechanism is required to 497 obtain the IPv6 connectivity. 499 Having in mind that users want plug-and-play devices/services and 500 that most of them do not have any knowledge about how the transition 501 mechanism works or where the nearest Tunnel Broker/Tunnel Sever, 6to4 502 relay, etc., are located, it is required considering the 503 auto-discovery of the IPv6 TS, so the device can find it 504 automatically. 506 Different transition mechanisms have different ways to encapsulate 507 IPv6 packets, so servers implementing different transition mechanisms 508 can be considered like different types of IPv6 end points (which of 509 course, can perfectly sit in a single server). For example, the 510 Tunnel Broker/Tunnel Server uses mainly 6in4 tunnels; TSP can used 511 either 6in4 or IPv6 over UDP tunnels; Teredo uses IPv6 over UDP 512 tunnel, etc. Furthermore, each transition mechanism has its own 513 tunnel setup handshake, so it is not only important to know where the 514 nearest IPv6 TS is located but also what type of transition 515 mechanism/s is able to manage. 517 On the other hand, there are situations where people are crowded, 518 i.e. either conferences, airports, urban areas with high population 519 density, etc. In this scenario is very likely that most of the users 520 choose a particular IPv6 TS, usually because it is nearer or more 521 well known. It is possible that while there exist a few IPv6 TS 522 attending many connections, there can exist a lot of them that are 523 not being used. In this way, most of the users have poor performance 524 in their connections while users using TS without congestion will 525 have good performance. It would be desirable that there were some 526 kind of load balancing in order to uniformly distribute the IPv6 527 tunnel requests among all available IPv6 TS. 529 The different approaches to cope with this issue are analysed in 530 [12]. 532 4. Nomadicity Considerations 534 When users move across networks, several situations are possible. 535 From the network point of view, users can or cannot maintain the IPv6 536 address assigned from their home TS. From the transition mechanism 537 point of view, the new one can or cannot require an authentication 538 process. So clearly some considerations are required regarding the 539 auto-transition algorithm behavior while user is moving. 541 1. Nodes that do not need to maintain the IPv6 address assigned from 542 their home TS. They are typically nomadic users who get 543 connectivity to "passive" Internet users (browsing, emailing, 544 etc.), but do not need to be "identified" from Internet 545 (nevertheless this situation is changing with next generation p2p 546 applications, VoIP, etc.). Looking for the best IPv6 547 connectivity can lead the auto-transition algorithm to define as 548 the best TS one of the following: 550 * TSs that do not require authentication process. They are TSs 551 that provide IPv6 connectivity and they do not make any 552 authentication process (TEREDO, 6to4, etc.). The 553 auto-transition approach does not offer any advantage in this 554 case, so the auto-transition algorithm will just contact to 555 the TS and the IPv6 connectivity will be obtained. 557 * TSs that require authentication process. They are TSs that 558 only provide IPv6 connectivity to authenticated users (users 559 that previously were somehow registered in the entity 560 providing the IPv6 TS service or some related entity). 561 Automatic AAA mechanism must be defined, in order to ensure 562 the no-human intervention requirement. The TS can or cannot 563 belong to the entity which the user was registered. If so, 564 authentication process is simpler. However, a global 565 authentication only will be possible if there are roaming 566 agreements between the entity that is selected to obtain IPv6 567 connectivity and the "home" entity which the user is 568 registered. These roaming agreements could be used for 569 billing purposes among others. If there are not such 570 agreements, automatic connectivity is not possible and the 571 auto-transition algorithm has two options: 573 + To choose an alternative transition mechanism, even 574 although it does not offer the best performance. 576 + To inform to the user that the best IPv6 connection is only 577 possible if a new manual registration/authentication 578 process is done. 580 * The behavior should be defined during the wizard installation 581 process of the auto-transition implementation. 583 2. Nodes that need to maintain the IPv6 address assigned from their 584 home TS. Users belonging to this group are typically users with 585 either server or peer-to-peer applications, devices that need to 586 be tracked (cars, suitcases, etc.), etc. MIPv6 should be applied 587 to this kind of nodes, but the following considerations must to 588 taken into account by the auto-transition algorithm: 590 * Mobility capability should be an option that should be 591 configured by means of the installation wizard. If chosen, 592 the first time that the auto-transition algorithm is run, it 593 must check if a Home Agent (HA) exists either in the current 594 IPv6 network or in the TS. In fact, this option should 595 condition the order of searching for the best transition 596 mechanism to get IPv6 connectivity. In this way, only 597 mechanisms compatible with the presence of HA should be taken 598 into account (mechanisms providing static IPv6 network prefix 599 like TB, TSP, ISATAP, etc.). The auto-transition algorithm 600 should record the mechanism used to get IPv6 connectivity. 601 Some transition mechanisms like ISATAP, allow the HA 602 deployment into the home network which the nomadic device is 603 initially attached. Others, like TB, could be deployed in 604 different networks from the one where the device is physically 605 attached, but the HA could be implemented into the TS that 606 provides the IPv6 connectivity. On the other hand, the 607 auto-transition algorithm should discard transition mechanisms 608 that build the IPv6 network prefix from the IPv4 address 609 (6to4, TEREDO, etc.). This is required because it is no 610 possible the deployment of the HA into the same IPv6 network, 611 so no mobility features would be possible. If no HA is 612 discovered the first time that the auto-transition algorithm 613 is run, then no MIPv6 support is possible, so the user should 614 be informed and the usual auto-transition algorithm must be 615 applied to get IPv6 connectivity. 617 * Once the node is away from home network, it needs to get IPv6 618 connectivity. The auto-transition algorithm should first 619 check if it possible to maintain the same IPv6 home address, 620 according to the mechanism used, before moving for getting the 621 home address. There are some kinds of transition mechanisms 622 that allow this operation like a TB with several TS 623 associated. In this scenario, the node first gets the IPv6 624 home address from a TS. After the node move to other 625 location, it could get IPv6 connectivity from a different TS 626 that is associated to the same TB. It is possible that either 627 the new TS has the same /64 network prefix that the old TS or 628 it can be configured by the TB to forward/send tunneled 629 packets coming/going from/to the nomadic node. In this way 630 the nomadic device could maintain the IPv6 home address. Even 631 if the new TS does not belong to the same TB but there are 632 roaming agreements between the involved entities, the 633 maintenance of the IPv6 address/prefix could be possible. How 634 to do this configuration is out of scope of this document. 636 * If the IPv6 home address can not be maintained, then once the 637 nomadic device has a new IPv6 address by means of any 638 transition mechanism, it must contact to the HA to communicate 639 the care of address following MIPv6. 641 Other considerations pointed out in [12] should be taken into 642 account. 644 5. Network Managed Transition 646 The algorithm described in this memo attempts to automatically and 647 autonomously provide the best possible IPv6 connectivity and follows 648 an approach based on the role of the user device Operating System. 649 However the algorithm and in general the transition, could be 650 improved and/or even more easily managed from the service provider 651 (SP) point of view, if the network provided services that could help 652 the auto-transition algorithm. Following this approach, we propose a 653 transitioning management architecture that in addition to providing 654 network management functionality to the providers' network can also 655 better support auto-transitioning hosts. 657 There are two basic alternatives for the network managed transition: 658 The use of Policy Based Networks (PBN) [13] or using a "transitioning 659 server". 661 [This section needs more text in order to explain how the 662 communication between PDP and PEPs will be done, interaction among 663 policies, how the different parameters like link, user identity and 664 so on can influence the transition mechanism chosen. Also other 665 options rather than just PBN, such as SNMP, can be further 666 described.] TBD. 668 5.1 Policy Based Networks 670 Policies stored on the network repository might include information 671 about the type of transition mechanisms implemented into the network 672 to which the user device is attached to, so the auto-transition 673 algorithm implemented into the user device would have more 674 information to choose a better one or directly those possible in that 675 network, or those suggested by the SP, or those enabled by the SP 676 policy. 678 In a more advanced behavior the auto-transition algorithm implemented 679 into the user device would inform to the Policy Decision Point (PDP), 680 about features such as type of connection, date/time, user privileges 681 and/or whatever other relevant information. Then, the PDP might 682 interact with other policies stored on the repository such as QoS 683 Policies, Security Policies and so on, in order to propose the more 684 adequate transition mechanism to be used by the device willing to get 685 IPv6 connectivity. 687 In accordance with [13], based on this approach the user device will 688 act as a Policy Enforcement Point (PEP) as well as implementing the 689 auto-transition algorithm. 691 5.2 Transitioning Server 693 Essentially, the architecture will provide a 'transitioning server' 694 which the host should automatically detect and register with to be 695 provided with the optimum IPv6 transitioning solution for its current 696 location within the network. This has a number of advantages both 697 from the administrators and auto-transitioning hosts point-of-view, 698 the primary one being that this will act as a single point of contact 699 for all auto-transitioning hosts within the network regardless of 700 their location and circumstances and so by default gives a degree of 701 control over this service to the administrator. A summary of the 702 advantages this provides are: 704 o Host 706 * Simplifies mechanism detection and configuration by explicitly 707 providing the host with mechanism location and configuration 708 information. 710 * Capable of supporting host roaming within the network (improves 711 hand-off procedure). 713 * Will act as a centralised authentication point for the 714 auto-transitioning host. 716 o Administrator 718 * Introduces administrative control to the auto-transitioning 719 procedure. 721 * Allows administrator to determine mechanism availability to 722 hosts. 724 * Provides admin with fine-grained control over host access 725 control. 727 * Can easily be extended to support performance provisioning to 728 user groups dependant upon privileges or service agreements. 730 This component also introduces a significant security consideration 731 to the process as adequate security precautions must be made to 732 protect the server from abuse. The server must be adequately 733 protected from both DoS-type attacks and exploitation/hacking. 735 The following sub-sections describe the auto-transition algorithm 736 modifications required for the host and server operation, in case the 737 network managed transition is being used. 739 5.3 Host operation 741 The host auto-transitioning algorithm will need minor modification in 742 order to make use of the transitioning management architecture. This 743 should reflect the fact that it represents an optimum solution when 744 compared to the host attempting to detect the transitioning 745 infrastructure individually but is less desirable than native IPv6 746 connectivity. Whether the network provides this type of transition 747 facilities or not, the auto-transition algorithm, when present, must 748 always attempt to provide the 'best' possible IPv6 connectivity. The 749 term 'best' is perhaps misleading as it actually represents the 750 optimum solution based on a number of criteria ranging from host or 751 auto-transitioning priorities, provider policies etc. We can 752 envisage the following alternatives: 754 o Both auto-transition algorithm and network managed transition are 755 present. The user device should be provided with the optimal 756 transition mechanism in this scenario. 758 o Only auto-transition algorithm present. Depending on the network, 759 the transition might not be "optimal", but the auto-transition 760 algorithm in the user device must be capable of providing some 761 level of "good enough" IPv6 connectivity. 763 o Only network managed transition present. The user device doesn't 764 support the auto-transition algorithm, but a set of managed 765 transition mechanisms in the network will be capable of offering 766 possibly a good alternative for IPv6 connectivity, again not 767 necessarily the optimal one. 769 o Neither mechanism is present. This is the case where a user 770 device has not been upgraded, but does include some transition 771 mechanisms. The provider is also not offering managed transition 772 and so if the operating system is not capable of offering an 773 automatic transition mechanism selection, the user device may 774 require manual user intervention or even not offer IPv6 775 connectivity at all. 777 The key aspect of this process will be in making the host capable of 778 detecting the presence of the PDP or transitioning server in the 779 network. In many ways, this is similar to the tunneling mechanism 780 auto-detection procedure described in [12] and so a similar approach 781 could be adopted here. Essentially it identifies a number of 782 approaches that could be used to automatically detect services 783 including DHCP, DNS names or shared unicast addresses and describes 784 the potential advantages and disadvantages of using each solution. 785 It concludes that due to the weaknesses of the other solutions, DNS 786 is the best solution here and recommends it for use in this case. 787 Due to the similarities of that problem and the one described here, 788 this solution could also be adopted for transitioning server 789 auto-detection, this would also serve to simplify the 790 auto-transitioning host algorithm if similar approaches are used. 791 This aspect is not described in more detail here but see the solution 792 document [14] for a more detailed explanation. 794 The modifications to the auto-transition algorithm to incorporate the 795 network managed transition architecture will be inserted in between 796 the native IPv6 availability and host auto-detection sections. This 797 is shown in the following algorithm: 799 loop 800 detect_scenario 801 if (native_IPv6_available and native_priority) 802 use_native_IPv6_connectivity 803 else 804 if (network_managed_transition available) 805 use_network_managed_transition 806 else 807 if (first_check or performance_check_allowed) 808 check_performance 809 use_best_mechanism 810 endif 811 endif 812 endif 813 configure_connectivity 814 wait (link_check_timeout) 815 endloop 817 Figure 2: Auto-Transition using Network Managed Transition 819 As you can see, the host will now check for native connectivity first 820 before attempting to find a network manager transition service and 821 only falling back on host detection if that too fails. 823 5.4 Server operation 825 One of the more interesting aspects of the introduction of the 826 network managed transition service will be the registration procedure 827 that hosts follow in order to make use of the service. This will 828 allow the service provider to keep track of the auto-transitioning 829 hosts within its network and to assign certain privileges or 830 priorities to the transitioning hosts, depending on administrative 831 policies. For example, hosts native to the network may receive a 832 better level of service (either through access to a better-performing 833 mechanisms or prioritised load-balancing) than 'foreign' hosts. 835 The introduction of the network managed transition service 836 essentially removes the transitioning mechanism selection procedure 837 from the hosts and unifies it within the server. This makes the 838 server responsible for determining which mechanisms to supply to the 839 hosts as they register and this could be done according to the 840 following algorithm: 842 loop 843 receive request from auto-transitioning host + authenticate 844 determine available mechanism(s) 845 if (more than one available) 846 rank mechanisms according to scoring algorithm 847 select 'best' mechanism 848 endif 849 reply to host 850 supply necessary configuration information to host 851 endloop 853 Figure 3: Determination of Auto-Transition using Network Managed 854 Transition 856 The interesting part of this procedure is the algorithm that is 857 applied to determine the most appropriate mechanism for the host in 858 the event that more than one solution is available. It is obviously 859 important that the administrator has control over this algorithm to 860 the extent that they will be able to determine who has access to 861 which services within their network. At a simple level, this could 862 be a 'default' list of mechanisms as described earlier in this draft 863 but has the potential to be expanded to take into account, for 864 example, the performance required by the host, host privileges and/or 865 administrative preferences. 867 Considering that most of the ISP will not necessarily deploy 868 transition mechanisms in the early stage, advanced IPv6 Internet 869 Exchanges could provide this kind of services [15] and in general 870 policy-based capabilities. The IX is not just a central peering 871 point which facilitates any new service deployment, but also a place 872 where lots useful information (routes, QoS, link conditions, etc.) 873 about several domains is available. With this philosophy, the 874 transition policies will be one more facility provided by this type 875 of IXs. 877 6. Conclusions 879 TBD. 881 7. Security Considerations 883 The auto-transition algorithm should secure at least the following 884 points: 886 1. Communication with TS for administrative purposes. 888 2. Communication with TS for authentication purposes. 890 3. Tunnel building is according to the chosen TS. 892 4. General tunnel security consideration pointed at [16]. 894 8. Acknowledgements 896 This memo was written as a consequence of real experience using IPv6 897 when traveling, number of talks during IETF meetings and specially 898 the work with the unmanaged, ISP and enterprise v6ops design teams. 899 The authors would also like to acknowledge inputs from Brian 900 Carpenter, Alvaro Vives, Cesar Olvera, Jim Bound, Stig Venaas and the 901 European Commission support in the co-funding of the Euro6IX project, 902 where this work is being developed. 904 9. References 906 9.1 Normative References 908 9.2 Informative References 910 [1] Thomson, S. and T. Narten, "IPv6 Stateless Address 911 Autoconfiguration", RFC 2462, December 1998. 913 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 914 Carney, "Dynamic Host Configuration Protocol for IPv6 915 (DHCPv6)", RFC 3315, July 2003. 917 [3] Palet, J., "Forwarding Protocol 41 in NAT Boxes", 918 draft-palet-v6ops-proto41-nat-03 (work in progress), October 919 2003. 921 [4] Huitema, C., "Evaluation of Transition Mechanisms for Unmanaged 922 Networks", draft-ietf-v6ops-unmaneval-03 (work in progress), 923 June 2004. 925 [5] Lind, M., Ksinant, V., Park, S., Baudot, A. and P. Savola, 926 "Scenarios and Analysis for Introducing IPv6 into ISP 927 Networks", draft-ietf-v6ops-isp-scenarios-analysis-03 (work in 928 progress), June 2004. 930 [6] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", 931 draft-ietf-v6ops-3gpp-analysis-10 (work in progress), May 2004. 933 [7] Bound, J., "IPv6 Enterprise Network Scenarios", 934 draft-ietf-v6ops-ent-scenarios-05 (work in progress), July 935 2004. 937 [8] Savola, P. and J. Soininen, "Evaluation of v6ops Tunneling 938 Scenarios and Mechanisms", draft-savola-v6ops-tunneling-01 939 (work in progress), April 2004. 941 [9] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and 942 B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, 943 August 1999. 945 [10] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and 946 G. Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 947 1999. 949 [11] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and 950 R. Wheeler, "A Method for Transmitting PPP Over Ethernet 951 (PPPoE)", RFC 2516, February 1999. 953 [12] Palet, J. and M. Diaz, "Evaluation of v6ops Auto-discovery for 954 Tunneling Mechanisms", draft-palet-v6ops-tun-auto-disc-01 (work 955 in progress), June 2004. 957 [13] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for 958 Policy-based Admission Control", RFC 2753, January 2000. 960 [14] Palet, J., "IPv6 Tunnel End-point Automatic Discovery 961 Mechanism", draft-palet-v6ops-solution-tun-auto-disc-00 (work 962 in progress), September 2004. 964 [15] Morelli, M., "Advanced IPv6 Internet Exchange model", 965 draft-morelli-v6ops-ipv6-ix-00 (work in progress), July 2004. 967 [16] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 968 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06 (work in 969 progress), September 2004. 971 Authors' Addresses 973 Jordi Palet Martinez 974 Consulintel 975 San Jose Artesano, 1 976 Alcobendas - Madrid 977 E-28108 - Spain 979 Phone: +34 91 151 81 99 980 Fax: +34 91 151 81 98 981 EMail: jordi.palet@consulintel.es 983 Miguel Angel Diaz Fernandez 984 Consulintel 985 San Jose Artesano, 1 986 Alcobendas - Madrid 987 E-28108 - Spain 989 Phone: +34 91 151 81 99 990 Fax: +34 91 151 81 98 991 EMail: miguelangel.diaz@consulintel.es 993 Michael Mackay 994 Lancaster University 995 Lancaster 996 United Kingdom 998 Phone: 999 Fax: 1000 EMail: m.mackay@lancaster.ac.uk 1002 Intellectual Property Statement 1004 The IETF takes no position regarding the validity or scope of any 1005 Intellectual Property Rights or other rights that might be claimed to 1006 pertain to the implementation or use of the technology described in 1007 this document or the extent to which any license under such rights 1008 might or might not be available; nor does it represent that it has 1009 made any independent effort to identify any such rights. Information 1010 on the procedures with respect to rights in RFC documents can be 1011 found in BCP 78 and BCP 79. 1013 Copies of IPR disclosures made to the IETF Secretariat and any 1014 assurances of licenses to be made available, or the result of an 1015 attempt made to obtain a general license or permission for the use of 1016 such proprietary rights by implementers or users of this 1017 specification can be obtained from the IETF on-line IPR repository at 1018 http://www.ietf.org/ipr. 1020 The IETF invites any interested party to bring to its attention any 1021 copyrights, patents or patent applications, or other proprietary 1022 rights that may cover technology that may be required to implement 1023 this standard. Please address the information to the IETF at 1024 ietf-ipr@ietf.org. 1026 Disclaimer of Validity 1028 This document and the information contained herein are provided on an 1029 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1030 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1031 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1032 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1033 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1034 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1036 Copyright Statement 1038 Copyright (C) The Internet Society (2004). This document is subject 1039 to the rights, licenses and restrictions contained in BCP 78, and 1040 except as set forth therein, the authors retain all their rights. 1042 Acknowledgment 1044 Funding for the RFC Editor function is currently provided by the 1045 Internet Society.