idnits 2.17.1 draft-palet-v6tc-goals-tunneling-00.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 26. -- Found old boilerplate from RFC 3978, Section 5.5 on line 927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 904. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 911. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 917. ** 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 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.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (February 14, 2005) is 7010 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) ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-3gpp-analysis (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 3904 (ref. '2') ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-isp-scenarios-analysis (ref. '3') ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ent-scenarios (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 3053 (ref. '5') ** Obsolete normative reference: RFC 2461 (ref. '6') (Obsoleted by RFC 4861) == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-06 -- Obsolete informational reference (is this intentional?): RFC 2222 (ref. '13') (Obsoleted by RFC 4422, RFC 4752) -- Obsolete informational reference (is this intentional?): RFC 3177 (ref. '16') (Obsoleted by RFC 6177) Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Palet 3 Internet-Draft Consulintel 4 Expires: August 18, 2005 K. Nielsen 5 Ericsson 6 F. Parent 7 Hexago 8 A. Durand 9 Sun Microsystems, inc. 10 R. Suryanarayanan 11 Samsung India Software Operations 12 P. Savola 13 CSC/FUNET 14 February 14, 2005 16 Goals for Tunneling Configuration 17 draft-palet-v6tc-goals-tunneling-00.txt 19 Status of this Memo 21 This document is an Internet-Draft and is subject to all provisions 22 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 23 author represents that any applicable patent or other IPR claims of 24 which he or she is aware have been or will be disclosed, and any of 25 which he or she become aware will be disclosed, in accordance with 26 RFC 3668. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on August 18, 2005. 46 Copyright Notice 48 Copyright (C) The Internet Society (2005). 50 Abstract 52 This memo describes the set of goals for a tunneling setup protocol 53 that could be used in several network cases to jumpstart its IPv6 54 offering to its customers by providing them IPv6 connectivity through 55 a simplistic tunneling mechanism. 57 The basic network cases, which may have different sets of goals, are 58 also introduced, including 3GPP and other Service Providers. Two 59 cases are analyzed in the Service Provider scenario, one which apply 60 to simplistic mechanism where the user is already authenticated by 61 other network existing means, and another which also takes care of 62 the user authentication. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Assumptions and Prerequisites . . . . . . . . . . . . . . . . 6 69 4. Goals of the Tunneling Configuration Protocol . . . . . . . . 7 70 4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1.1 Simplicity . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1.2 Easy to deploy and Easy to Phase-out . . . . . . . . . 7 73 4.2 Tunnel Set-up . . . . . . . . . . . . . . . . . . . . . . 8 74 4.2.1 Tunnel End-Point Auto-Discovery and tunnel 75 establishment . . . . . . . . . . . . . . . . . . . . 8 76 4.2.2 Tunnel End-Point Reachability Detection . . . . . . . 8 77 4.2.3 Scalability and Load-Balancing . . . . . . . . . . . . 9 78 4.2.4 Latency in Set-up Phases . . . . . . . . . . . . . . . 9 79 4.2.5 Tunnel Link Sustainability . . . . . . . . . . . . . . 9 80 4.2.6 NAT Traversal . . . . . . . . . . . . . . . . . . . . 10 81 4.2.7 Firewall Traversal . . . . . . . . . . . . . . . . . . 10 82 4.2.8 Use Native Connectivity when Available . . . . . . . . 10 83 4.3 IPv6 Configuration . . . . . . . . . . . . . . . . . . . . 10 84 4.3.1 IPv6 Address Assignment . . . . . . . . . . . . . . . 10 85 4.3.2 IPv6 Address Stability . . . . . . . . . . . . . . . . 11 86 4.3.3 IPv6 Prefix Delegation . . . . . . . . . . . . . . . . 11 87 4.3.4 IPv6 DNS . . . . . . . . . . . . . . . . . . . . . . . 11 88 4.4 Implementation Considerations . . . . . . . . . . . . . . 11 89 4.4.1 Private and Public IPv4 Addresses . . . . . . . . . . 11 90 4.4.2 Extensibility . . . . . . . . . . . . . . . . . . . . 11 91 4.4.3 Stateful or Stateless . . . . . . . . . . . . . . . . 12 92 4.5 Management and Security . . . . . . . . . . . . . . . . . 12 93 4.5.1 Security . . . . . . . . . . . . . . . . . . . . . . . 12 94 4.5.2 Traceability . . . . . . . . . . . . . . . . . . . . . 12 95 4.5.3 Registration . . . . . . . . . . . . . . . . . . . . . 12 96 4.5.4 Authentication . . . . . . . . . . . . . . . . . . . . 13 97 4.5.5 Confidentiality . . . . . . . . . . . . . . . . . . . 13 98 4.5.6 Accounting . . . . . . . . . . . . . . . . . . . . . . 13 99 5. Applicability of the Tunneling Configuration to Different 100 Network Cases . . . . . . . . . . . . . . . . . . . . . . . . 14 101 5.1 3GPP Access Networks . . . . . . . . . . . . . . . . . . . 14 102 5.1.1 Simplicity . . . . . . . . . . . . . . . . . . . . . . 15 103 5.1.2 Automated IPv6-in-IPv4 tunnel establishment . . . . . 15 104 5.1.3 IPv6 Address Assignment and Prefix Delegation . . . . 15 105 5.1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 106 5.1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 107 5.1.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 108 5.1.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 109 5.2 Narrowband Access Networks . . . . . . . . . . . . . . . . 16 110 5.3 Broadband Access Networks . . . . . . . . . . . . . . . . 16 111 5.4 Unmanaged Networks . . . . . . . . . . . . . . . . . . . . 16 112 5.5 Enterprise Networks . . . . . . . . . . . . . . . . . . . 16 113 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 114 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 115 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 116 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 117 9.1 Normative References . . . . . . . . . . . . . . . . . . . 17 118 9.2 Informative References . . . . . . . . . . . . . . . . . . 17 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 120 Intellectual Property and Copyright Statements . . . . . . . . 21 122 1. Introduction 124 Regardless of which is the network that is involved in the transition 125 from IPv4 to IPv6, generally this could involve several phases, often 126 in different networks parts (i.e., core, access). 128 The transition of the core network usually can be done in a much more 129 easy way than the access network. This is the case even if the core 130 network is only connected via tunnels to other IPv6 networks. The 131 setup of those tunnels involves a small effort and is not a big 132 trouble, even in the case of a manual configuration. 134 However, this is not the case for the access network, which may 135 involve different types of layer two technologies. In all the cases, 136 in order to facilitate the transition of those access networks, which 137 will be impossible to do manually and efficiently, there is a need 138 for an automatic IPv6-in-IPv4 tunneling mechanism. The goal is to 139 provide bidirectional IPv6-in-IPv4 tunneled connectivity between 140 dual-stack end-nodes located at an IPv4-only access network and 141 dual-stack tunnel servers located at IPv6/IPv4 network boundaries. 143 This should be applicable to all kind of ISPs and access networks. 144 They could be regular ISPs, providing service through DSL, PSTN, 145 ISDN, cable, PLC or any other technologies, but could be also a 146 wireless ISP, or even an enterprise with its own service provider 147 infrastructure for the employees at remote locations. 149 In order to simplify the text, "customers" is used in the rest of 150 this document to refer to both Customers of Service Providers (3GPP, 151 other ISPs) and users (Enterprise, others). 153 In this document, the refereces to "Service Provider" is a general 154 one, meaning whatever network/technology is used for providing access 155 to IP connectivity. 157 In the case of an ISP starting its IPv6 offering to its customers, 158 without initially upgrading its access network to support IPv6, as 159 indicated in section 5.1 of [3], could use a "tunnel brokering 160 solution", as described in [5]. However the tunnel set-up protocol 161 has been identified as a missing piece. 163 Similarly, in an 3GPP, ISP or enterprise network, the provision of 164 the native IPv6 connectivity to the customers/users, can take a long 165 time and may be costly, while a tunneled infrastructure can be used 166 as a low cost transition path, which can be deployed easily and in a 167 short time, enabling progressive native IPv6 deployment when/where 168 justified. 170 Such tunneling infrastructure can connect the customers/users to the 171 IPv6 network using available production IPv6 address space, thus 172 facilitating the transition towards native IPv6 deployment, so the 173 roadmap may become: 175 o Tunneling infrastructure for early adopters. 177 o Native IPv6 to some customers/user groups once economically 178 justified. 180 o Native IPv6 to all customers/users. 182 "Tunneling Configuration" (TC) is used in this document to describe a 183 protocol which takes care of the setup and maintenance of the 184 bidirectional tunnel between a dual-stack end-node (or leaf network) 185 and a dual-stack tunnel server. The exchange of parameters needed 186 for the setup and maintenance of the tunnel (such as address, prefix, 187 routing, encapsulation, filtering, authentication, accounting, ...), 188 should be automated to avoid manual user/operator intervention. 190 The tunneling configuration protocol is envisaged to be deployed as 191 an initial and temporary mechanism to provide basic IPv6 connectivity 192 services only. This basic IPv6 connectivity may be limited, in the 193 sense than may be not 100% comparable to a native IPv6 service. 194 However this basic IPv6 connectivity should be enough while it allows 195 the communication through IPv6 during the transition phase, until the 196 native IPv6 service is available, and consequently is expected that 197 the tunneling will be phased out as soon as native IPv6 access 198 service is available. 200 This document analyzes the goals for a such tunnel setup protocol, 201 taking in consideration the different possible common network cases 202 for deploying IPv6. 204 2. Terminology 206 Tunneling-Configured Site (TCS): A logical network over which IPv6 207 connectivity is provided by means of Tunneling Configuration. At 208 least one dual-stack node is required in this logical network. 210 Tunnel End-Point (TEP): A dual-stack node performing IPv6-in-IPv4 211 tunnel encapsulation/decapsulation in accordance with Tunneling 212 Configuration. There will be always two TEPs in order to establish 213 the communication, the local one at the customer site (TCS) and the 214 remote one at the ISP site. 216 Tunnel Server (TS): A dual-stack server node with IPv6 connectivity 217 and which provides IPv6 connectivity to client nodes by performing 218 IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from client nodes 219 in accordance with Tunneling Configuration. A Tunnel Server is 220 likely to be a dual-stack router, but could be also a node behaving 221 as a router. The TS is often the ISP TEP. 223 Tunnel Client (TCL): A dual-stack node that obtains IPv6 connectivity 224 by means of Tunneling Configuration. A tunnel client relies on 225 IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from Tunnel 226 Servers for IPv6 communications to native IPv6 nodes. This is often 227 the customer TEP. 229 Direct Tunneling (DT): Direct tunnelling here refer to the case where 230 end-hosts located within different Tunneling-Configured Sites, in the 231 same ISP network, may circumvent the Tunnel Server and communicate 232 directly using the tunnel protocol. 234 CPE: Customer Premises Equipment. 236 3. Assumptions and Prerequisites 238 Tunneling Configuration may be applicable in different IPv6 239 transition network cases. The focus of this document is to define 240 the goals to apply this mechanism in the Service Provider context 241 making the following assumptions and prerequisites: 243 o The customer configuration may be diverse and not necessarily 244 predictable. Consequently the tunneling configuration protocol 245 must be able to adapt to different cases or combinations of: 247 * The TCS is a single node or leaf network. 249 * The TCL at the TCS has a global IPv4 address or is behind one 250 or more NATs. 252 * The TCL at the TCS has a static or dynamic IPv4 address. 254 * In case of NAT, the external IPv4 address is a static or 255 dynamic. 257 * In case of NAT, it can be customer or ISP owned. 259 o IPv4 multicast is not widely available, so the tunnel 260 configuration protocol should work in IPv4 network environments 261 where IPv4 multicast is not provided. 263 o The tunnel configuration protocol should be simple to implement 264 and easy to deploy. In particular, it should not depend on any 265 complex, yet to be designed, protocols or infrastructure pieces. 267 o This tunneling configuration protocol is provided within a 268 restrictive timescale, in the sense that it should be phased out 269 as soon as native access can be provided. 271 o The tunneling configuration is a protocol to be used in the 272 transition phase, thus does not need to be perfect. As a matter 273 of fact, making it perfect would be counter productive, as it 274 would first delay its definition, then make its deployment more 275 cumbersome and, last but not least, diminish the incentives to 276 deploy native IPv6. Furhermore, should not rely in a complex set 277 of devices, which may not be readily available, and could even 278 mean a more expensive cost than the support of native IPv6 itself. 280 4. Goals of the Tunneling Configuration Protocol 282 As introduced above, there are different ISP types and different 283 access networks. This means that that there are different goals 284 related to different network cases and situations. For instance, 285 factors as presence of NAT or not, low/high bandwidth, 286 expensive/cheap, strong internal access control or not, etc. 288 Different access media or network cases brings up different sets of 289 goals. Obviously, once choice will be to create a protocol for each 290 specific case, but this is not optimal. Instead, the motivation of 291 this document is to combine all the goals and look for a common 292 solution, which can fit as much as possible and in the most optimal 293 way, in all the cases. Some of those goals could be conflictual and 294 that need to be resolved as well. 296 This section groups these different goals. 298 4.1 General 300 4.1.1 Simplicity 302 The Tunneling Configuration protocol should be easy to implement, 303 implying a lightweight protocol. The protocol should provide a 304 reasonable, even if limited, set of basic IPv6 connectivity features. 306 4.1.2 Easy to deploy and Easy to Phase-out 308 The Tunneling Configuration protocol should be easy to deploy into 309 the existing IPv4 and IPv6 network infrastructure. 311 The Tunneling Configuration protocol should have no major impact on 312 protocols and infrastructure nodes deployed in existing 313 infrastructures providing IPv4 and native IPv6 connectivity. 315 The Tunneling Configuration protocol should coexist and work 316 seamlessly together with any native IPv6 infrastructure that 317 gradually may be implemented in the network. The Tunneling 318 Configuration protocol should have no negative implications on how 319 such infrastructure is implemented. 321 The Tunneling Configuration protocol should be easy to take out of 322 service once native IPv6 is available. 324 4.2 Tunnel Set-up 326 4.2.1 Tunnel End-Point Auto-Discovery and tunnel establishment 328 The tunnel protocol should provide a mechanism for the automated 329 discovery of the Tunnel End-Point, by the virtue of which end-hosts 330 automatically and at run-time can determine the IPv4 addresses of 331 available Tunnel Servers. 333 The discovery mechanism should rely on intrinsic services, read 334 services already universally deployed, to the particular network 335 environment. It should not require the addition of additional IP 336 network infrastructure elements for this function only. 338 The mechanism should be fully dynamic in the sense that it must not 339 require IP address information such as the IPv4 address of a Tunnel 340 Server and/or the IPv6 address(es) to use for IPv6 connectivity to be 341 configured on the Tunnel Clients beforehand. 343 The analysis done in [11] may apply. 345 The Tunneling Configuration protocol should provide for the set of 346 IPv6-in-IPv4 tunnels, based on IPv6-in-IPv4 encapsulation as defined 347 in [10], from dual-stack nodes, attached to IPv4-only networks, to 348 Tunnel Servers. 350 The IPv6-in-IPv4 tunnels and the IPv6 connectivity should be 351 established in an automated manner, i.e., without requiring manual 352 intervention at any of the tunnel end-points at tunnel establishment 353 time. We can typically describe it as a "plug and play" protocol, 354 which can be triggered through the execution of a simple program. 356 4.2.2 Tunnel End-Point Reachability Detection 358 The Tunneling Configuration protocol should allow for means for one 359 tunnel end-point to verify the reachability of other tunnel 360 end-points towards which it intends to send packets in a method 361 similar to IPv6 NUD. 363 The unicast neighbor reachability discovery functions provided by 364 IPv6 Neighbor Discovery ([6]), i.e., unicast NS/NA exchanges, should 365 be supported on the tunnel link. 367 It is preferable that a Tunnel Server monitors the reachability of 368 the tunnel client towards which it is sending packets. Full 369 emulation of IPv6 NUD mechanism is however not an explicit goal. 371 4.2.3 Scalability and Load-Balancing 373 In order to ensure the scalability of the tunnel service, in terms of 374 not limiting the number of simultaneous connections to the service 375 and consequently limiting possible service denial situations, it 376 should be possible for a Service Provider to load-balance those 377 connections among several available Tunnel Servers. 379 Load balancing should be planned already during the early phases of 380 deployment. Given adequate planning it should be possible for an ISP 381 to seamlessly deploy additional Tunnel Servers in order to support an 382 increased amount of Tunnel Clients. 384 This may be achieved, for example, by using the load balancing 385 functions provided by the Tunnel Server End-point discovery mechanism 386 as detailed in [12]. 388 4.2.4 Latency in Set-up Phases 390 In certain type of networks, keeping tunnels active all the time is 391 not possible. In such environments, the protocol must be able to 392 set-up tunnels on demand when the IPv6 connectivity either natively 393 or through tunneling is unavailable. The tunnel will be set-up only 394 once though for the tunnel client and not per session. 396 The Tunneling Configuration protocol must then have a low enough 397 latency to enable quasi-instant configuration. Latency is usually a 398 function of the number of packet exchanges required, so minimizing 399 this parameter is important. 401 4.2.5 Tunnel Link Sustainability 403 The tunnel link established in between a host deploying Tunneling 404 Configuration and an associated Tunnel Server should be expected to 405 remain in administrative active state for the lifetime of the IPv6 406 address provided to the host. 408 The Tunneling Configuration protocol should not mandate keep-alive 409 messages to be transmitted by the host simply in order to sustain 410 tunnel link connectivity. However, this may be required when a 411 tunnel has to cross a NAT box. In this case, the mapping established 412 by the NAT must be preserved as long as the tunnel is in use. This 413 is usually achieved by sending keep-alive messages across the tunnel. 415 Also, the same keep-alive messages can enable the ISP tunnel end 416 point to perform garbage collection of its resources when tunnels are 417 not in use anymore. To enable those two functionalities, the tunnel 418 set-up protocol must include the transmission of keep-alive messages. 419 A client may choose not to send those messages (for example on 3GPP 420 or ISDN type links). In this case, the client should be able to 421 handle a tunnel disconnect event and be able to restart the set-up 422 phase to re-establish the tunnel. 424 4.2.6 NAT Traversal 426 The Tunneling Configuration protocol should be able to detect the 427 presence of one or more NATs in its path. 429 The tunnel should be able to traverse NAT, if present, so it may be 430 necessary to choose among several tunnel encapsulation protocols for 431 the most optimal one. 433 4.2.7 Firewall Traversal 435 Even if no NAT is in the tunnel path, there may be a firewall which 436 prohibits proto-41. In such case, the tunnel encapsulation selection 437 based on NAT detection could select a tunnel that will not work. 439 To cope with this situation, the Tunnel Configuration protocol 440 implementation may allow a user to explicitly specify the desired 441 tunnel encapsulation, regardless of the NAT detection process. 443 4.2.8 Use Native Connectivity when Available 445 The node should not use the Tunneling Configuration protocol when 446 native IPv6 connectivity is available. 448 The fact that a node should not initiate the Tunneling Configuration 449 protocol when native IPv6 connectivity is available is not considered 450 to be a functional goal on the tunnel protocol per se. For example, 451 rather it is related to the activation and deactivation of the 452 protocol. 454 4.3 IPv6 Configuration 456 4.3.1 IPv6 Address Assignment 458 Assignment of at least one globally routable IPv6 unicast address 459 (/128) to the end-node should be supported. 461 No goals are defined as to how address configuration should be 462 performed. This may be done based on stateless or stateful IPv6 463 address configuration mechanisms or by some altogether different 464 mechanism particular to the Tunneling Configuration protocol. 466 4.3.2 IPv6 Address Stability 468 The IPv6 address is "transient" and may change, but the protocol 469 should offer a mechanism to provide IPv6 address stability (for 470 example, a cookie mechanism). The implementation of this mechanism 471 should allow this feature to be turned off. 473 It is preferable that the address assignment provides a stable 474 address, that is, an address that can be used for IPv6 connectivity 475 for a certain amount of time rather than solely one address per 476 higher layer session initiation. 478 4.3.3 IPv6 Prefix Delegation 480 Prefix Delegation support may depend on the different deployment 481 cases. It is not however required that a Tunneling Configuration 482 protocol supporting only basic requirements provides support for 483 prefix delegation. 485 4.3.4 IPv6 DNS 487 Dual-stack nodes could use both IPv4 and IPv6 DNS discovery 488 mechanisms and both, IPv4 and IPv6 transport for DNS services. 490 Consequently IPv6 DNS discovery and IPv6 transport for DNS services 491 should not be a goal of the Tunneling Configuration protocol. 493 4.4 Implementation Considerations 495 4.4.1 Private and Public IPv4 Addresses 497 The Tunneling Configuration protocol should work over IPv4 sites 498 deploying both private and public IPv4 addresses. 500 Furthermore, the Tunneling Configuration protocol should work with 501 both dynamic and static IPv4 address allocation. 503 4.4.2 Extensibility 505 The Tunneling Configuration protocol should be extensible to support 506 tunnel encapsulation other than IPv6 in IPv4 and IPv6 in transport in 507 IPv4. In particular, encapsulation of IPv4 in IPv6 or IPv6 in IPv6 508 could be defined. 510 4.4.3 Stateful or Stateless 512 By a stateful mechanism we mean a mechanism that require the Tunnel 513 Server to maintain tunnel state per client it serves. 515 Tunnel state here is considered to be any parameter kept by the 516 server per client and without which the server is unable to serve the 517 client (receive packets from/send packets to). 519 Tunnel state must be distinguished from state used to optimize the 520 packet delivery function of the tunnel server and which is kept in a 521 fixed or upper limited amount of memory space, such as, e.g., 522 reachability information. 524 It should be emphasized that this document makes no deliberate 525 assumptions on whether a Tunneling Configuration protocol should be 526 based on a stateful or stateless Tunnel Server mechanism. Indeed it 527 is anticipated that the goals of Tunneling Configuration as put 528 forward here could be served both by a stateless as well as by a 529 stateful mechanism. 531 4.5 Management and Security 533 4.5.1 Security 535 The Tunneling Configuration protocol should not impose any new 536 vulnerability to the existing network infrastructure. 538 The Tunneling Configuration protocol should not impose any new 539 vulnerability to the nodes implementing it than what is already 540 present in existing multi-access IPv6 networks, where multiple hosts 541 are served by the same router or possibly multiple routers. 543 4.5.2 Traceability 545 In some environments, traceability is an important consideration. 546 The Tunneling Configuration protocol should be instrumentable to 547 enable the collection of usage data which can be used, for example, 548 for capacity planning. 550 4.5.3 Registration 552 The registration of credentials should be external to the Tunneling 553 Configuration protocol. The user may require registration prior to 554 using this service (through some web based service or other means). 556 Alternatively, the service provider may use an existing 557 authentication database to pre-register its users, or even not 558 require registration at all, depending on the network configuration. 560 In order to allow a service provider to use its existing 561 authentication database, an implementation may provide hooks to 562 facilitate integration with the ISP management infrastructure (e.g. 563 RADIUS for AAA, billing). 565 The protocol may send information about registration procedure when a 566 non-registered client requests access to a registered mode (e.g. URL 567 to provider registration web page). 569 4.5.4 Authentication 571 Authentication can be used to control that the user has access to the 572 IPv6 services. 574 The authentication mechanism supported should be compatible with 575 standardized methods that are generally deployed. In order to assure 576 interoperability, at least one common authentication method should be 577 supported. Other authentication may be supported and should be 578 negotiated between the client and server (e.g., SASL [13]). 580 4.5.5 Confidentiality 582 Tunneling Configuration can be used across networks which are not 583 under the service provider control (e.g., roaming users). The 584 Tunneling Configuration protocol should allow protection of the 585 authentication data. This can be achieve by selecting an 586 authentication mechanism that protects the credentials (e.g., 587 digest-md5). 589 Protecting the tunneled data (IPv6 in this case) should be possible, 590 for instance by means of using IPsec tunneling. 592 4.5.6 Accounting 594 The Tunneling Configuration should include tools for managing and 595 monitoring the provided service. Such information can be used to 596 plan service capacity (traffic load) or billing information. 598 Some useful accounting data are (not exhaustive list): 600 o Tunnel counters (traffic in/out). 602 o User utilization (tunnel uptime). 604 o System logging (authentication failures, resource exhaustion, 605 etc.). 607 The interface used to provide such information can be through SNMP or 608 an AAA protocol (e.g., RADIUS accounting). 610 5. Applicability of the Tunneling Configuration to Different Network 611 Cases 613 Note: Section to be completed in a new version. 615 The goals enumerated in the precedent section are not all necessarily 616 applicable and not in the same degree to different network cases. 617 However seems feasible to build a common ground to these different 618 network cases in order to define a single Tunneling Configuration 619 protocol, which can accommodate to the different combinations of 620 those goals and network cases. 622 The v6ops working group has identified and analyzed several 623 deployment scenarios for IPv4/IPv6 transition mechanisms in various 624 stages of the IPv6 deployment and its coexistence with IPv4. 626 This work has been carried out for a number of different network 627 environments each with their particular characteristics including 628 3GPP [1], Unmanaged [2], ISP [3] and Enterprise networks [4]. 630 The following sub-sections basically look into those different 631 network environments to provide an analysis of the common and 632 uncommon goals. 634 5.1 3GPP Access Networks 636 IPv6-in-IPv4 tunneling is envisaged to be deployed in 3GPP networks 637 as an initial and temporary mechanism to provide limited and basic 638 IPv6 connectivity services only. The IPv6-in-IPv4 tunneling 639 mechanism demanded by the 3GPP environment falls within the realm of 640 Tunneling Configuration. 642 Native IPv6-like 3GPP connectivity services, e.g. services including 643 flexible charging and quality of service on demand, will be feasible, 644 in 3GPP environments by virtue of true native IPv6 only. This is due 645 to the interrelation between the native IPv6 3GPP service and various 646 3GPP signaling interfaces. The latter which is not envisaged 647 upgraded to support the IPv6-in-IPv4 tunneling situation. 649 It is important to note that the IPv6 connectivity provided by 3GPP 650 Tunneling Configuration IPv6-in-IPv4 tunneling does not compare with 651 the native IPv6 3GPP connectivity in terms of the services offered. 653 This differentiates the 3GPP IPv6-in-IPv4 tunneling transition case 654 somewhat from some of the other transition scenarios considered in 655 the IETF v6ops WG and unlike some of these scenarios, the 3GPP 656 IPv6-in-IPv4 tunneling deployment case is not a case of progressive 657 and gradual roll out of native IPv6-like services. Rather, Tunneling 658 Configuration will in the 3GPP environment be deployed for the 659 following purposes: 661 o To provide temporary provisioning of basic IPv6 services, which 662 users may deploy for the simplest IPv6 services only. 664 o To allow an Operator, possibly a native IPv6 enabled Operator, to 665 provide basic IPv6 services to users roaming into foreign networks 666 which supports IPv4 bearer connectivity only. 668 The scope of Tunneling Configuration in the 3GPP network environment 669 is restricted to an absolute minimal set of functions required to 670 provide automatic IPv6 connectivity establishment to dual stack nodes 671 by means of IPv6-in-IPv4 encapsulation as defined in [10] to Tunnel 672 Servers. 674 Tunneling Configuration in the 3GPP network environment does not 675 attempt to provide emulation of the full set of native IPv6 676 connectivity functions as defined by [14], [15] and [16]. 678 With this in mind the following goals are applicable to the 3GPP 679 Access Networks: 681 5.1.1 Simplicity 683 . 685 5.1.2 Automated IPv6-in-IPv4 tunnel establishment 687 . 689 5.1.3 IPv6 Address Assignment and Prefix Delegation 691 It is only an explicit goal to have a /128 address allocated for 692 global connectivity on the tunnel link. 694 5.1.4 696 . 698 5.1.5 700 . 702 5.1.6 704 . 706 5.1.7 708 . 710 5.2 Narrowband Access Networks 712 Somehow this type of networks are very similar to the 3GPP case, 713 because the main constrain is the low bandwidth and the high cost of 714 the usage of the access network. Examples of this are PSTN and ISDN 715 access networks. 717 . 719 5.3 Broadband Access Networks 721 This is typically the case when an ISP is offering IPv6 connectivity 722 to its customers, initially using controlled tunneling 723 infrastructure, as described in section 5.1 "Steps in Transitioning 724 Customer Connection Networks" of [3]. 726 . 728 5.4 Unmanaged Networks 730 In unmanaged networks [2], Tunneling Configuration is applicable in 731 the case A where a gateway does not provide IPv6 at all (section 3), 732 and case C where a dual-stack gateway is connected to an IPv4-only 733 ISP (section 5). 735 In the case the link is not IPv4 capable, Tunneling Configuration is 736 applicable by means of IPv4 in IPv6 tunneling. 738 This will actually fall into the same set of goals as already 739 described for narrow or broadband access networks, depending on the 740 media. 742 5.5 Enterprise Networks 744 In the enterprise scenario [4], Tunneling Configuration can be used 745 to support both, remote users connecting to the enterprise network 746 (section 7.5.2) and internal users if the native infrastructure is 747 not yet available. 749 6. Conclusions 751 TBD. 753 7. Security Considerations 755 TBD. 757 8. Acknowledgements 759 This memo was written starting from previous existing work at v6ops, 760 such as "Goals for Zero-Configuration Tunneling in 3GPP" [7], 761 "Zero-Configuration Tunneling Requirements" [8] and "Goals for 762 Registered Assisted Tunneling" [9]. The authors would also like to 763 acknowledge inputs from Tim Chown and the European Commission support 764 in the co-funding of the Euro6IX project, where this work is being 765 developed. 767 9. References 769 9.1 Normative References 771 [1] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", 772 Internet-Draft draft-ietf-v6ops-3gpp-analysis-11, October 2004. 774 [2] Huitema, C., Austein, R., Satapati, S. and R. van der Pol, 775 "Evaluation of IPv6 Transition Mechanisms for Unmanaged 776 Networks", RFC 3904, September 2004. 778 [3] Lind, M., Ksinant, V., Park, S., Baudot, A. and P. Savola, 779 "Scenarios and Analysis for Introducing IPv6 into ISP Networks", 780 Internet-Draft draft-ietf-v6ops-isp-scenarios-analysis-03, June 781 2004. 783 [4] Bound, J., "IPv6 Enterprise Network Scenarios", 784 Internet-Draft draft-ietf-v6ops-ent-scenarios-05, July 2004. 786 [5] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel 787 Broker", RFC 3053, January 2001. 789 [6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 790 IP Version 6 (IPv6)", RFC 2461, December 1998. 792 9.2 Informative References 794 [7] Nielsen, k., "Goals for Zero-Configuration Tunneling in 3GPP", 795 Internet-Draft draft-nielsen-v6ops-3GPP-zeroconf-goals-00, 796 October 2004. 798 [8] Suryanarayanan, R., "Zero-Configuration Tunneling 799 Requirements", 800 Internet-Draft draft-suryanarayanan-v6ops-zeroconf-reqs-00, 801 October 2004. 803 [9] Parent, F., "Goals for Registered Assisted Tunneling", 804 Internet-Draft draft-ietf-v6ops-assisted-tunneling-requirements-01 805 , October 2004. 807 [10] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 808 IPv6 Hosts and Routers", 809 Internet-Draft draft-ietf-v6ops-mech-v2-06, September 2004. 811 [11] Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point 812 Discovery Mechanisms", 813 Internet-Draft draft-palet-v6ops-tun-auto-disc-03, January 814 2005. 816 [12] Palet, J., "IPv6 Tunnel End-point Automatic Discovery 817 Mechanism", 818 Internet-Draft draft-palet-v6ops-solution-tun-auto-disc-01, 819 October 2004. 821 [13] Myers, J., "Simple Authentication and Security Layer (SASL)", 822 RFC 2222, October 1997. 824 [14] Wasserman, M., "Recommendations for IPv6 in Third Generation 825 Partnership Project (3GPP) Standards", RFC 3314, September 826 2002. 828 [15] Loughney, J., "IPv6 Node Requirements", 829 Internet-Draft draft-ietf-ipv6-node-requirements-11, August 830 2004. 832 [16] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 833 Allocations to Sites", RFC 3177, September 2001. 835 Authors' Addresses 837 Jordi Palet Martinez 838 Consulintel 839 San Jose Artesano, 1 840 Alcobendas - Madrid 841 E-28108 - Spain 843 Phone: +34 91 151 81 99 844 Fax: +34 91 151 81 98 845 Email: jordi.palet@consulintel.es 847 Karen Egede Nielsen 848 Ericsson 849 Skanderborgvej 232 850 8260 Viby J 851 zip - Denmark 853 Phone: +45 89 38 51 00 854 Fax: 855 Email: karen.e.nielsen@ericsson.com 857 Florent Parent 858 Hexago 859 2875 boul. Laurier, suite 300 860 Sainte-Foy, QC G1V 2M2 861 Canada 863 Phone: 864 Fax: 865 Email: florent.parent@hexago.com 867 Alain Durand 868 Sun Microsystems, inc. 869 17 Network Circle UMPK17-202 870 Menlo Park, CA 94025 871 USA 873 Phone: 874 Fax: 875 Email: alain.durand@sun.com 876 Radhakrishnan Suryanarayanan 877 Samsung India Software Operations 878 No. 3/1 Millers Road 879 Bangalore 880 India 882 Phone: +91 80 51197777 883 Fax: 884 Email: rkrishnan.s@samsung.com 886 Pekka Savola 887 CSC/FUNET 888 Espoo 889 Finland 891 Phone: 892 Fax: 893 Email: psavola@funet.fi 895 Intellectual Property Statement 897 The IETF takes no position regarding the validity or scope of any 898 Intellectual Property Rights or other rights that might be claimed to 899 pertain to the implementation or use of the technology described in 900 this document or the extent to which any license under such rights 901 might or might not be available; nor does it represent that it has 902 made any independent effort to identify any such rights. Information 903 on the procedures with respect to rights in RFC documents can be 904 found in BCP 78 and BCP 79. 906 Copies of IPR disclosures made to the IETF Secretariat and any 907 assurances of licenses to be made available, or the result of an 908 attempt made to obtain a general license or permission for the use of 909 such proprietary rights by implementers or users of this 910 specification can be obtained from the IETF on-line IPR repository at 911 http://www.ietf.org/ipr. 913 The IETF invites any interested party to bring to its attention any 914 copyrights, patents or patent applications, or other proprietary 915 rights that may cover technology that may be required to implement 916 this standard. Please address the information to the IETF at 917 ietf-ipr@ietf.org. 919 Disclaimer of Validity 921 This document and the information contained herein are provided on an 922 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 923 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 924 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 925 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 926 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 927 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 929 Copyright Statement 931 Copyright (C) The Internet Society (2005). This document is subject 932 to the rights, licenses and restrictions contained in BCP 78, and 933 except as set forth therein, the authors retain all their rights. 935 Acknowledgment 937 Funding for the RFC Editor function is currently provided by the 938 Internet Society.