idnits 2.17.1 draft-nielsen-v6ops-3GPP-zeroconf-goals-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.5 on line 970. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 948. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 954. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Bad filename characters: the document name given in the document, 'draft-nielsen-v6ops-3GPP-zeroconf-goals-00', contains other characters than digits, lowercase letters and dash. == There is 1 instance of lines with non-ascii characters in the document. == 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 5, 2004) is 7143 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-04 == Outdated reference: A later version (-11) exists of draft-ietf-v6ops-3gpp-analysis-10 == Outdated reference: A later version (-01) exists of draft-ietf-v6ops-assisted-tunneling-requirements-00 == Outdated reference: A later version (-03) exists of draft-palet-v6ops-tun-auto-disc-01 == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-node-requirements-10 -- Obsolete informational reference (is this intentional?): RFC 3177 (ref. '9') (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '12') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '13') (Obsoleted by RFC 4861) == Outdated reference: A later version (-01) exists of draft-palet-v6ops-solution-tun-auto-disc-00 Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Nielsen 3 INTERNET-DRAFT Ericsson 4 M. Morelli 5 Expires: April 4, 2005 Telecom Italia Lab 6 J. Palet 7 Consulintel 8 J. Soininen 9 Nokia 10 J. Wiljakka 11 Nokia 13 October 5, 2004 15 Goals for Zero-Configuration Tunneling in 3GPP 16 18 Status of this memo 20 By submitting this Internet-Draft, I certify that any applicable 21 patent or other IPR claims of which I am aware have been disclosed, 22 and any of which I become aware will be disclosed, in accordance with 23 RFC 3668 (BCP 79). 25 By submitting this Internet-Draft, I accept the provisions of Section 26 [#3] of RFC 3667 (BCP 78). 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that other 30 groups may also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or cite them other than as "work in progress". 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/lid-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Abstract 45 Various types of IPv6-IPv4 tunneling are envisaged to be required in 46 the transition period from IPv4 networking to IPv6 networking, or 47 more precisely, in the transition period from IPv4 only networking to 48 dual or mixed IPv6 and IPv4 networking. 50 Zero-Configuration Tunneling is the term used for a minimalistic 51 IPv6-in-IPv4 automatic tunneling mechanism that could be used by a 52 Service Provider to offer IPv6 connectivity to its customers in early 53 phases of IPv4 to IPv6 transition. 55 This document describes the set of goals to be fulfilled by a Zero- 56 Configuration Tunneling protocol in the 3GPP environment. 58 Table of Contents 60 1. Introduction.....................................................3 61 2. Terminology......................................................4 62 3. Scope and Limitations............................................5 63 3.1. IPv6 address allocation, Scope and Limitations:.............5 64 3.2. IPv6 tunnel link characteristics, Scope and Limitations:....5 65 4. Assumptions and Prerequisites....................................6 66 4.1. Applicability Assumptions...................................6 67 4.2. 3GPP Prerequisites..........................................6 68 5. Timing...........................................................7 69 6. Goals............................................................7 70 6.1. Simplicity..................................................8 71 6.2. Automated IPv6-in-IPv4 tunnel establishment.................8 72 6.3. Use native when available...................................9 73 6.4. Easy to deploy and Easy to Phase-out with no modifications on 74 existing equipment...............................................9 75 6.5. Tunnel Server End-Point Auto-Discovery.....................10 76 6.6. Address Assignment.........................................10 77 6.7. Tunnel Link Sustainability.................................10 78 6.8. Tunnel End-Point Reachability Detection....................11 79 6.9. Private and public IPv4 addresses..........................11 80 6.10. Scalability, Load Balancing...............................11 81 6.11. Security..................................................11 82 7. Non Goals.......................................................11 83 7.1. NAT and Firewall Traversal.................................12 84 7.2. IPv6 DNS...................................................12 85 7.3. Extensibility..............................................12 86 7.4. Registration burden........................................12 87 8. Stateful or Stateless...........................................12 88 9. Security Considerations.........................................13 89 9.1. Threats to existing network infrastructures................13 90 9.2. Threats to nodes implementing Zero-Configuration Tunneling.14 91 9.2.1. Threats to end-hosts..................................14 92 9.2.2. Threats to Tunnel Servers.............................15 93 9.2.2.1. Tunnel State related risks.......................15 94 9.2.2.2. Traffic related risks............................15 95 9.2.2.3. Packet Delivery related threats..................16 96 9.3. Implications of Direct Tunneling...........................16 97 10. Acknowledgments................................................17 98 11. Authors Addresses..............................................17 99 12. Changes from draft-nielsen-v6ops-zeroconf-goals-01.txt.........18 100 13. Informative References.........................................18 101 Appendix A Out of Scope............................................19 103 1. Introduction 105 The IETF v6ops Working Group has identified and analyzed deployment 106 scenarios for IPv4/IPv6 transition mechanisms in various stages of 107 IPv6 deployment and IPv6 and IPv4 coexistence. 109 This work has been carried out for a number of different network 110 environments each with their particular characteristics: Enterprise, 111 ISP, Unmanaged and 3GPP networks, see e.g., [2], [3] and [4]. 113 The work has identified a need for automatic IPv6-in-IPv4 tunneling 114 mechanisms that provide bidirectional IPv6-in-IPv4 tunneled 115 connectivity between dual stack end-nodes located at an IPv4-only 116 access network and dual-stack tunnel servers located at IPv6-IPv4 117 network boundaries within the Service Providers network. 119 The term Zero-Configuration Tunneling is used to denote a simplistic 120 automatic IPv6-in-IPv4 tunneling mechanism. 122 Zero-Configuration Tunneling is intended to provide a basic set of 123 tunneling features only, and intentionally so. The scope of Zero- 124 Configuration Tunneling is not to provide emulation of the full suite 125 of native IPv6 connectivity functions as defined by [7], [8] and [9]; 126 rather the focus is to provide a minimal set of features required for 127 automatic establishment of IPv6 connectivity. 129 IPv6-in-IPv4 tunneling is envisaged to be deployed in 3GPP networks 130 as an initial and temporary mechanism to provide limited and basic 131 IPv6 connectivity services only. The IPv6-in-IPv4 tunneling mechanism 132 demanded by the 3GPP environment falls within the realm of Zero- 133 Configuration Tunneling. 135 Native IPv6 like 3GPP connectivity services, e.g. services including 136 flexible charging and quality of service on demand, will in 3GPP 137 environments be feasible by virtue of true native IPv6 only. This is 138 due to the interrelation between the native IPv6 3GPP service and 139 various 3GPP signaling interfaces. The latter which is not envisaged 140 upgraded to support the IPv6-in-IPv4 tunneling situation. 142 It is important to note that the IPv6 connectivity provided by 3GPP 143 Zero-Configuration IPv6-in-IPv4 tunneling does not compare with the 144 native IPv6 3GPP connectivity in terms of the services offered. This 145 differentiates the 3GPP IPv6-in-IPv4 tunneling transition case 146 somewhat from some of the other transition scenarios considered in 147 the IETF v6ops WG and unlike some of these scenarios, the 3GPP IPv6- 148 in-IPv4 tunneling deployment case is not a case of progressive and 149 gradual roll out of native IPv6-like services. Rather, Zero- 150 Configuration tunneling will in the 3GPP environment be deployed for 151 the following purposes: 152 - To provide temporary provisioning of basic IPv6 services, which 153 users may deploy for the simplest IPv6 services only. 154 - To allow an Operator, possibly a native IPv6 enabled Operator, 155 to provide basic IPv6 services to users roaming into foreign 156 networks which supports IPv4 bearer connectivity only. 158 Unless otherwise specified then in this document the reference, IPv6- 159 in-IPv4 encapsulation as defined in [1], refers to the aspects of 160 Protocol-41 encapsulation related to IPv4 header construction (except 161 for source and destination address determination), MTU and 162 Fragmentation, Hop Limits and ICMP handling as detailed in Section 163 3.1-3.6 of [1]. The particular aspects of Configured IPv6-In-IPv4 164 Tunneling in the areas of IPv4 source and destination address 165 determination, tunnel link characteristics and IPv6 Neighbor 166 Discovery operation are not intended referred to by the above 167 reference. 169 2. Terminology 171 Zero-Configuration Tunneling site: 172 A logical IPv4 network over which IPv6 connectivity is provided to 173 dual-stack nodes by means of Zero-Configuration Tunneling. 175 Tunnel End-point: 176 A dual-stack node performing IPv6-in-IPv4 tunnel 177 encapsulation/decapsulation in accordance with Zero-Configuration 178 Tunneling. 180 Tunnel Server: 181 A dual-stack server node with IPv6 connectivity and which provides 182 IPv6 connectivity to client nodes by performing IPv6-in-IPv4 tunnel 183 encapsulation/decapsulation to/from client nodes in accordance with 184 Zero-Configuration Tunneling. 186 A Tunnel Server is likely to be a dual-stack router. 188 Tunnel Client: 189 A dual-stack node that obtains IPv6 connectivity by means of Zero- 190 Configuration Tunneling. A tunnel client relies on IPv6-in-IPv4 191 tunnel encapsulation/decapsulation to/from Tunnel Servers for IPv6 192 communications to native IPv6 nodes. 194 Direct Tunneling: 195 Direct tunneling here refer to the case where end-hosts located 196 within the same Zero-Configuration Tunneling site may circumvent the 197 Tunnel Server and communicate directly using the tunnel protocol. 199 3. Scope and Limitations 201 The scope of Zero-Configuration Tunneling in the 3GPP network 202 environment is restricted to an absolute minimal set of functions 203 required to provide automatic IPv6 connectivity establishment to dual 204 stack nodes by means of IPv6-in-IPv4 encapsulation as defined in [1] 205 to Tunnel Servers under the assumptions and prerequisites described 206 in Section 4. 208 Zero-Configuration Tunneling in the 3GPP network environment does not 209 attempt to provide emulation of the full set of native IPv6 210 connectivity functions as defined by [7], [8] and [9]. 212 3.1. IPv6 address allocation, Scope and Limitations: 214 The primary goal of 3GPP Zero-Configuration Tunneling is to provide 215 IPv6 connectivity to nodes on an individual basis. By this it is 216 meant that it is only an explicit goal to have a /128 address 217 allocated for global connectivity on the tunnel link. As such optimal 218 IPv6 connectivity provisioning in Personal Area Network (PAN) 219 scenarios is not explicitly within the scope of Zero-Configuration 220 Tunneling. 222 It is not explicitly within the scope of Zero-Configuration Tunneling 223 in the 3GPP network environment to support usage of privacy IPv6 224 extensions as defined in [12]. 226 It is not explicitly within the scope to support usage of IPv6 227 multicast. 229 No goals are defined as to how address configuration should be 230 performed. This may be done based on legacy stateless or stateful 231 IPv6 address configuration mechanisms or by some altogether different 232 mechanism particular to the zero-configuration solution. 234 3.2. IPv6 tunnel link characteristics, Scope and Limitations: 236 Direct tunneling is neither an explicit goal nor explicitly excluded 237 in Zero-Configuration Tunneling in the 3GPP network environment. 239 It is not an explicit requirement for the 3GPP Zero-Configuration 240 tunnel link to support IPv6 link-local multicast. 242 The tunnel protocol should allow for the formation of a link-local 243 address on the tunnel link. Though no particular usage of such an 244 address is explicitly demanded by the goals set forward here. 246 It is an explicit goal that nodes attached to a tunnel link must be 247 able to ascertain the reachability of neighbors with which they are 248 communicating (or wish to start communicate). This may be achieved 249 using IPv6 Neighbor Discovery mechanism ([13]) based on unicast link- 250 local packet exchanges (or link-local multicast if such is supported) 251 but it may also be achieved by altogether different mechanisms. 253 4. Assumptions and Prerequisites 255 4.1. Applicability Assumptions 257 The aim of the document is to define the set of goals to be fulfilled 258 by 3GPP Zero-Configuration Tunneling when the following assumptions 259 are made on the 3GPP deployment environment: 261 - IPv4 source addresses spoofing within the Zero-Configuration 262 Tunneling site is prevented. 263 - The Zero-Configuration Tunneling site is protected from 264 protocol-41 encapsulated packets arriving from external IPv4 265 networks. 266 - At least one authoritative DNS server is IPv4-enabled and at 267 least one recursive DNS server supports IPv4. Further IPv4 DNS 268 Server discovery is provided by already existing means/means 269 outside the scope of the tunnel protocol. 270 - The user is being authenticated to the network by means external 271 to the tunneling protocol and other than that no additional 272 authentication/registration mechanisms are required. 274 Plus in addition: 276 - There are no NATs in between the tunnel endpoints in the Zero- 277 Configuration Tunneling site. 278 - The Zero-Configuration Tunneling network is fully penetrable for 279 intra-site IPv6-in-IPv4 Protocol 41 traffic. 281 Finally, it is a prerequisite that the tunnel protocol must work in 282 IPv4 network environments, as the 3GPP network environment, where 283 IPv4 multicast is not provided. 285 The above assumptions are readily applicable to the 3GPP tunneling 286 transition scenario described in [4], section 3.1. The specific 287 transition scenario considered there and here is the scenario where a 288 3GPP UE deploys IPv6-in-IPv4 tunneling towards a Tunnel Server 289 located in its Home Operators network, this regardless of whether the 290 UE is located at an IPv4-only segment of its Home Operators network 291 or at an IPv4-only segment of a Foreign Operators network. In both 292 cases, it is assumed that the 3GPP UE is attached to the logical IPv4 293 network of its Home Operator, i.e., the Home Operator provides the 294 IPv4 address and the logical first hop link, read the IPv4 PDP 295 context, is terminated at a GGSN of its Home Operator. 297 4.2. 3GPP Prerequisites 299 3GPP Zero-Configuration Tunneling must work over 3GPP wireless 300 networks. When considering the characteristics of 3GPP network links 301 and mobile terminals / User Equipment (UE), the following points need 302 to be taken into account: 303 - Link bandwidth (tunnel overhead / usage cost) 304 - Link latency 305 - UE battery power and derived implications on memory and 306 processing power 308 It is thus an explicit requirement for 3GPP Zero-Configuration 309 Tunneling to comply well with the constrained conditions put on the 310 above parameters by the 3GPP environments. The latter which commonly 311 is recognized as translating into requirements for the protocol to 312 operate with a limited number of message exchanges, small packet 313 sizes and simple message processing. 315 In this context it is note worthy that average round trip times in 316 3GPP networks can be in the size of 0.2 to 1.5 seconds (0.2 to 0.8 317 for 3G, 0.8 to 1.5 for 2.5G). This fact alone illustrates the need to 318 keep the number of message exchanges required for tunnel 319 initialization at an absolute minimum. 321 Here we shall refer to a protocol as being lightweight when its 322 demands on message exchanges, packet sizes and message processing 323 complexity are sufficiently light for it to be readily applicable in 324 environments characterized by the constrained conditions of 3GPP 325 networks (as described above). 327 As a mean to ensure that the protocol be lightweight it is considered 328 preferable for the protocol to provide a simple set of functions 329 only, even if it provides only a basic IPv6 service compared to the 330 native one. It is although acknowledged that additional functionality 331 doesn't necessarily automatically add complexity to the demands on 332 the aforementioned parameters. 334 5. Timing 336 For the purpose of 3GPP deployment it is a prerequisite that this 337 tunneling protocol is provided within a very restrictive timescale. 339 3GPP Release 6 documents, which ideally should refer to an 340 appropriate solution, are being finalized at the time of writing of 341 this document. 343 Trial deployments, in which zero-configuration type of IPv6 344 connectivity is provided in 3GPP environments, are starting up using 345 experimental protocols at the time of writing this document. 347 6. Goals 349 The goals to be achieved by Zero-Configuration Tunneling in the 3GPP 350 network environment are detailed in the following subsections. 352 6.1. Simplicity 354 By simplicity, we understand a tunnel protocol that is easy to 355 implement in the targeted environment. Additionally, the protocol 356 should provide a reasonable, limited set of basic IPv6 connectivity 357 features. 359 Further by simplicity we imply that the protocol must be lightweight. 361 6.2. Automated IPv6-in-IPv4 tunnel establishment 363 The protocol should provide for the set up of IPv6-in-IPv4 tunnels, 364 based on IPv6-in-IPv4 encapsulation as defined in [1], from dual- 365 stack nodes, attached to IPv4-only networks, to Tunnel Servers. 367 The IPv6-in-IPv4 tunnels and the IPv6 connectivity must be 368 established in an automated manner, i.e., without requiring manual 369 intervention at any of the tunnel end-points at tunnel establishment 370 time. 372 The mechanism must be fully dynamic in the sense that it must not 373 require IP address information such as the IPv4 address of a Tunnel 374 Server and/or the IPv6 address(es) to use for IPv6 connectivity to be 375 configured on the Tunnel Clients beforehand. 377 Comment: 379 This goal is set to ensure that tunneled IPv6 connectivity can be 380 established in an automated manner by invocation of the Zero- 381 Configuration Tunneling function on an IPv4 network link. 383 For IPv6 connectivity to be established automatically, processes 384 within the node must be responsible for automatic invocation of the 385 Zero-Configuration Tunneling function when appropriate. The operation 386 of such activation - and deactivation - processes, as well as the 387 indicators on which such mechanisms may rely to determine the 388 appropriateness of tunneling, is not considered to be part of the 389 tunnel protocol processing per se and is considered to be an issue 390 for the node implementers. 392 Generally speaking, however, it is anticipated that such processes 393 will operate on the knowledge of whether IPv6 connectivity can be 394 established or not, for a 3GPP UE specifically whether IPv6 PDP 395 context activation succeeds or not. 397 No goals are set as to whether Zero-Configuration Tunneling should be 398 activated as default when native IPv6 connectivity is not available 399 or only by an applications demand for (tunneled) IPv6 connectivity. 400 As the general PDP context activation policies of an UE, e.g., see 401 the considerations given in Section 3.1 of [4], this is considered 402 determined by implementers, application developers and operators. 404 Further refinements of how the automated process should be carried 405 out, and of the nature of the (IPv6) connectivity that should be 406 provided, is given in some of the subsequent goals. 408 6.3. Use native when available 410 The protocol must in no way restrict the native IPv6 capabilities of 411 the client node. 413 The node should not initiate Zero-Configuration Tunneling when native 414 IPv6 connectivity is available. 416 Comment: 418 The fact that a node should not initiate Zero-Configuration Tunneling 419 when native IPv6 connectivity is available is not considered to be a 420 functional requirement on the tunnel protocol per se. Rather it is 421 related to the activation and deactivation of the Zero-Configuration 422 Tunneling function. 424 On a 3GPP UE this translates into saying that the PDP context and 425 Zero-Configuration Tunneling activation policies implemented on the 426 UE should ensure that activation of IPv6 PDP contexts (when possible) 427 take precedence over activation of Zero-Configuration Tunneling over 428 IPv4 PDP contexts. 430 The extend to which a 3GPP UE may try for native IPv6 availability, 431 i.e., attempt for IPv6 PDP context activation, while moving around, 432 is, as the general PDP context activation policies of an UE, left to 433 be determined by UE implementers, application developers and 434 operators. Possible choices could be to attempt for IPv6 PDP context 435 activation once every time the IPv4 connectivity changes (e.g., IPv4 436 PDP context deactivation due to roaming out of operator range) or, 437 once every time a new IPv6 connectivity request is received from an 438 application. Attempts for IPv6 PDP context activation could in 439 principle also be done on the basis of Routing Area changes (change 440 of SGSN). 442 6.4. Easy to deploy and Easy to Phase-out with no modifications on 443 existing equipment 445 The tunnel protocol should be easy to deploy into the existing IPv4 446 and IPv6 network infrastructure. 448 The tunnel protocol should have no major impact on protocols and 449 infrastructure nodes deployed in existing infrastructures providing 450 IPv4 and native IPv6 connectivity. 452 The tunnel protocol should coexist and work seamlessly together with 453 any native IPv6 infrastructure that gradually may be implemented in 454 the network. The tunnel protocol should have no negative implications 455 on how such are implemented. 457 The tunnel protocol must be easy to take out of service once native 458 IPv6 is available. 460 6.5. Tunnel Server End-Point Auto-Discovery 462 The tunnel protocol must provide a mechanism for automated end-point 463 discovery by the virtue of which end-hosts automatically and at run- 464 time can determine the IPv4 addresses of available Tunnel Servers. 466 The discovery mechanism should rely on intrinsic services, read 467 services already universally deployed, to the particular network 468 environment. It should not require the addition of additional IP 469 network infrastructure elements for this function only. 471 Comment: The analysis done in [6] may apply. 473 6.6. Address Assignment 475 The tunnel protocol must allow for the assignment of at least one 476 globally routable (/128) IPv6 unicast address to use for tunneled 477 IPv6 connectivity over the link provided by the Zero-Configuration 478 Tunneling mechanism. 480 It is preferable that the address assignment provides a stable 481 address, that is, an address that can be used for IPv6 connectivity 482 for a certain amount of time rather than solely one address per 483 higher layer session initiation. 485 6.7. Tunnel Link Sustainability 487 The tunnel link established in between a host deploying Zero- 488 Configuration Tunneling and an associated Tunnel Server should be 489 expected to remain in administrative active state for the lifetime of 490 the IPv6 address provided to the host. 492 The tunnel protocol must not mandate keep-alive messages to be 493 transmitted by the host simply in order to sustain tunnel link 494 connectivity. 496 Motivation: The fact that a 3GPP terminal, for the single purpose of 497 transmitting keep-alive messages, could have to wake up the radio 498 periodically, send a packet over the radio and possibly wait for 499 response is undesirable for the following reasons: 500 - The terminal cannot, as otherwise anticipated, be in dormant 501 mode all the time it is idle. This has severe implications for 502 the battery consumption of the device. 503 - Radio resources are costly and sparse and consequently not to be 504 used for what is considered to be unnecessary traffic. 506 6.8. Tunnel End-Point Reachability Detection 508 The tunnel protocol must allow for means for one tunnel end-point to 509 verify the reachability of other tunnel end-points towards which it 510 intends to send packets. 512 The unicast neighbor reachability discovery functions provided by 513 IPv6 Neighbor Discovery ([13]), i.e., unicast NS/NA exchanges, should 514 be supported on the tunnel link. 516 6.9. Private and public IPv4 addresses 518 The tunnel protocol must work over IPv4 sites deploying both private 519 and public IPv4 addresses. 521 Furthermore, the tunnel protocol should work with both dynamic and 522 static IPv4 address allocation. 524 Motivation: Private IPv4 addresses are widely used in current 3GPP 525 networks. 527 6.10. Scalability, Load Balancing 529 In order to ensure the scalability of the tunnel service, in terms of 530 not limiting the number of simultaneous connections to the service 531 and consequently limiting possible service denial situations, it 532 should be possible for a Service Provider to load-balance those 533 connections among several available Tunnel Servers. 535 Load balancing should be planned already during the early phases of 536 deployment. Given adequate planning it should be possible for a 537 Service Provider to seamlessly deploy additional Tunnel Servers in 538 order to support an increased amount of Tunnel Clients. 540 Comment: This may be achieved using load-balancing functions provided 541 by the Tunnel Server End-point Discovery mechanism as detailed in 542 [14]. 544 6.11. Security 546 The tunnel protocol should not impose any new vulnerability to the 547 existing 3GPP network infrastructure. 549 The tunnel protocol should not impose any new vulnerability to the 550 nodes implementing the tunnel protocol than what is already present 551 in existing multi-access IPv6 networks, where multiple hosts are 552 served by the same router or possibly multiple routers. 554 7. Non Goals 555 Non-goals of 3GPP Zero-Configuration Tunneling are detailed in the 556 following subsections. 558 With the term Non-goals we refer to features that generally are 559 believed to be applicable to tunneling, but which are not among the 560 minimal set of required features of 3GPP Zero-Configuration 561 Tunneling. The latter primarily because of the assumptions made on 562 the applicability environments for 3GPP Zero-Configuration Tunneling, 563 e.g., see Section 4. 565 7.1. NAT and Firewall Traversal 567 NAT and Firewall traversal is not required due to the assumptions on 568 the applicability environment. 570 Moreover to minimize the tunneling overhead applied to the packets as 571 well as in order to minimize the number of tunnel set-up signaling 572 messages exchanged on the link, it is preferable that the protocol 573 does not deploy the UDP encapsulation techniques, on which mechanisms 574 able to traverse NATs and Firewalls normally rely. 576 7.2. IPv6 DNS 578 By virtue of the assumptions on the applicability environments, the 579 dual stack end-hosts can use IPv4 DNS discovery mechanisms and IPv4 580 transport for DNS services. 582 Given that IPv4 based DNS services are already available, it is not 583 considered a requirement that the end-host should be able to deploy 584 IPv6 based DNS services. Consequently, the tunnel protocol does not 585 need to provide IPv6 DNS discovery mechanisms. 587 7.3. Extensibility 589 As a minimal tunneling mechanism Zero-Configuration Tunneling targets 590 IPv6 connectivity provisioning only. The protocol does not need to be 591 readily extendable to other encapsulation mechanisms, e.g., IPv4-in- 592 IPv6. 594 7.4. Registration burden 596 Tunnel service registration is not required due to the assumptions on 597 the applicability environment. 599 In order to keep the simplicity and minimize the tunnel overhead it 600 is desirable that the tunnel protocol not in itself (e.g., in order 601 to meet the goals put forward in this document) mandates 602 authenticated registration of the user. 604 8. Stateful or Stateless 605 By a stateful mechanism we mean a mechanism that require the Tunnel 606 Server to maintain tunnel state per client it serves. 608 Tunnel state here is considered to be any parameter kept by the 609 server per client and without which the server is unable to serve the 610 client (receive packets from/send packets to). 612 Tunnel state must be distinguished from state used to optimize the 613 packet delivery function of the tunnel server and which is kept in a 614 fixed or upper limited amount of memory space, such as, e.g., 615 reachability information. 617 It should be emphasized that this document makes no deliberate 618 assumptions on whether a Zero-Configuration Tunneling solution should 619 be based on a stateful or stateless Tunnel Server mechanism. Indeed 620 it is anticipated that the goals of zero-configuration as put forward 621 here could be served both by a stateless as well as by a stateful 622 mechanism. 624 9. Security Considerations 626 It is considered reasonable to assume that the following assumptions 627 of Section 4 are valid in the particular 3GPP network environment: 629 - IPv4 source addresses spoofing within the Zero-Configuration 630 Tunneling site is prevented. 631 - The Zero-Configuration Tunneling site is protected from 632 protocol-41 encapsulated packets arriving from external IPv4 633 networks. 635 It is worthwhile to note that together these assumptions imply that 636 the IPv4 source of all protocol-41 tunneled packets is legitimate. 638 9.1. Threats to existing network infrastructures 640 As stated in Section 6.11 the tunnel protocol should not impose any 641 new vulnerability to the existing network infrastructure. 643 The following have been identified as potential threats opened up for 644 by the deployment of Zero-Configuration Tunneling: 646 - As the tunnel service is un-authenticated (not registered) it 647 may be possible to use a tunnel server to reflect tunneled 648 packets into the network, similar to the 6to4-reflection attacks 649 identified in [10]. 650 - The Zero-configuration site must be kept fully penetrable for 651 intra-site IPv6-in-IPv4 protocol-41 encapsulated packets. This 652 may open up for threats to end-hosts that rely on the network 653 infrastructure to filter out bogus protocol-41 encapsulated 654 packets. 656 - Zero-configuration tunneling may open up for threats to other 657 mechanisms in the network that rely on Protocol-41 658 encapsulation. 660 Detailed analysis of the validity of these threats will have to 661 depend on the particular Zero-Configuration solution. In general it 662 could be noted that attacks based on the above threats largely should 663 be preventable if the end-hosts in the network implement appropriate 664 drop policies, either simple drop all protocol-41 policies or more 665 differentiated policies based, e.g., on source addresses. 667 The only known additional protocol-41 based mechanism that may be 668 deployed in the 3GPP environment are Configured Tunnels ([1]) and in 669 this case unauthorized packets should be dropped by the Configured 670 Tunnel implementation. 672 9.2. Threats to nodes implementing Zero-Configuration Tunneling 674 The following considerations apply to the situation where Zero- 675 Configuration Tunneling is deployed in between tunnel servers and 676 end-hosts only. 678 Special security considerations for the usage of Zero-Configuration 679 Tunneling for direct tunneling in between end-hosts is given in 680 Section 9.3. 682 As stated in Section 6.11 the tunnel protocol should not impose any 683 new vulnerability to the nodes implementing the tunnel protocol than 684 what is already present in existing multi-access IPv6 networks where 685 multiple hosts are served by the same router or possible multiple 686 routers. 688 Here it is implicitly assumed that the tunnel server(s) take the role 689 of default routers and the end-nodes using Zero-Configuration 690 Tunneling for IPv6 connectivity the role of hosts in multi-access 691 environments. 693 9.2.1. Threats to end-hosts 695 Given that all IPv4 sources of protocol-41 tunneled packets can be 696 assumed to be legitimate, threats stemming from encapsulated packets 697 sourced by nodes (addresses) other than nodes (addresses) which the 698 end-hosts recognize as tunnel servers (identified by addresses) can, 699 if not already an intrinsic part of the Zero-Configuration protocol, 700 easily be mitigated by the implementation of appropriate 701 differentiated (source addresses) drop policies in the end-hosts, 702 i.e., accept only if source is tunnel server. 704 In current multi-access IPv6 networks hosts need to trust on the 705 benevolence of their default routers as well as hosts must trust that 706 anyone impersonating as a router is indeed one, see, e.g., the trust 707 models and threats described in [11]. 709 Future multi-access IPv6 networks may rely on SEND mechanisms, i.e., 710 mechanisms developed in the SEND WG in order to mitigate the threats 711 described in [11], to establish a trust relations ship in between 712 host and routers. 714 Given that IPv4 source address spoofing is not possible in Zero- 715 Configuration Tunneling sites, then 716 - for an end-host to trust that packets it perceives as stemming 717 from tunnel servers do actually stem from such - as well as � 718 - for an end-host to trust on the benevolence of its tunnel 719 servers, 720 it suffices that a trustworthy tunnel server end-point discovery 721 mechanism, read discovery of benevolent tunnel servers IPv4 722 address(es), is implemented. 724 In open environments, such as indeed the 3GPP environment, it is 725 assumed a prerequisite that a trustworthy Zero-Configuration tunnel 726 server end-point discovery mechanism is implemented. 728 9.2.2. Threats to Tunnel Servers 730 Zero-Configuration Tunneling may be deployed over very large IPv4 731 sites with low density of active tunnel clients but with a very high 732 number of dormant, but potential tunnel clients. Therefore Denial of 733 Service prevention by strict over provisioning of Tunnel Server 734 capacity is unlikely to be performed. 736 9.2.2.1. Tunnel State related risks 738 If the Tunnel Server relies on state to be kept per tunnel client 739 that it serves, the server risks resource exhaustion. 741 In this situation it is a security prerequisite that no node, whether 742 located within or outside the Zero-Configuration Tunneling site, can 743 initiate initialization of tunnel state for other entities than 744 itself. 746 Further it is a security prerequisite that the amount of tunnel 747 state, e.g. one tunnel per client only, created and maintained per 748 Tunnel Client, identified by e.g. its IPv4 address, is limited. 750 Given these prerequisites, then for tunnel server resource exhaustion 751 by tunnel state creation to be categorized as a security threat, 752 rather than a case of under provisioning, requires a large number of 753 tunnel clients to operate in co-action. This is thus not considered a 754 plausible threat. 756 9.2.2.2. Traffic related risks 757 Tunnel encapsulation is recognized as being more resource demanding 758 than mere packet forwarding. Given the same traffic load a Tunnel 759 Server must thus be more generously provisioned that a corresponding 760 router for it not to be more likely to get overthrown by large 761 unexpected amounts of traffic than the router. 763 The authors have found no plausible treats to the tunnel service, due 764 to large unexpected amounts of traffic needing encapsulation, which 765 can be classified as a security threat rather than a case of under 766 provision. This regardless of whether the traffic is due to a surge 767 in the density of active tunnel clients or due to a surge in the 768 traffic streams set-up by active clients. 770 9.2.2.3. Packet Delivery related threats 772 One potential risk related to packet delivery has been identified. 773 This risk is the equivalent of the threat to routers in multi-access 774 environments described in [11], Section 4.3.2. 776 The risk is associated with the special case where the tunnel 777 protocol requires special resource demanding and/or temporary state 778 creation actions to be taken by the Tunnel Server for delivery of 779 packets destined for not recently addressed Tunnel Clients. The 780 situation where such actions must be performed for all packets at all 781 times is considered to be unlikely. The actions required could be 782 buffering of packets while the reachability of the destined node is 783 being verified. 785 In case a malicious node (located either within or outside the zero- 786 configuration site) is able to continuously send packets to 787 continuously changing nodes, which by the Tunnel Server is perceived 788 as being existing or potential client nodes, the malicious node may 789 be able to exhaust the Tunnel Servers capability of delivering 790 packets by saturating the packet buffering mechanism and the 791 reachability state table as well as by keeping the Tunnel Server busy 792 determining the reachability state of the ever changing client nodes. 794 9.3. Implications of Direct Tunneling 796 In case direct tunneling in between end-hosts is provided by the 797 tunneling protocol, it will not (as described in Section 9.2.1) be 798 possibly for end-hosts to filter out received Protocol-41 799 encapsulated packets based on whether the IPv4 source is an address 800 belonging to a trusted Tunnel Server as such behavior evidently would 801 break direct tunneling. 803 As other end-hosts generally are non-trusted, direct tunneling may 804 thus open up for attacks against IPv6 ingress filtering. 806 Detailed analysis of the validity of this threat will have to depend 807 on the particular zero-configuration solution. 809 10. Acknowledgments 811 Prior work by J. Mulahusic on the requirements for UE tunneling has 812 been considered in the initial stage of the work. 814 This work has benefited from input and comments provided by Fred 815 Templin in the initial phase of the work. 817 Thanks are due to Pekka Savola and Radhakrishnan Suryanarayanan for 818 many helpful comments and suggestions for improvements. 820 Corresponding work on assisted-tunneling, [5], has been an 821 inspiration for the Zero-Configuration Tunneling work. 823 The authors would like to acknowledge the European Commission support 824 in the co-funding of the Euro6IX project, where part of this work is 825 being developed. 827 11. Authors Addresses 829 Mario Morelli 830 Telecom Italia Lab. 831 Via Guglilmo Reiss Romoli, 274 832 I-10148 Turin, 833 Italy 835 Phone: +39 011 228 7790 836 Fax: +39 011 228 5069 837 Email: mario.morelli@tilab.com 839 Karen Egede Nielsen 840 Ericsson 841 Skanderborgvej 232 842 8260 Viby J 843 Denmark 845 Phone: + 45 89 38 51 00 846 Email: karen.e.nielsen@ericsson.com 848 Jordi Palet Martinez 849 Consulintel 850 San Jose Artesano, 1 851 Alcobendas - Madrid 852 E-28108 - Spain 853 Phone: +34 91 151 81 99 854 Fax: +34 91 151 81 98 855 EMail: jordi.palet@consulintel.es 857 Jonne Soininen 858 Nokia 859 Linnoitustie 6 860 02600 ESPOO 861 Finland 863 Phone: +358 7180 08000 864 EMail: jonne.soininen@nokia.com 866 Juha Wiljakka 867 Nokia 868 Visiokatu 3 869 33720 TAMPERE 870 Finland 872 Phone: +358 7180 48372 873 EMail: juha.wiljakka@nokia.com 875 12. Changes from draft-nielsen-v6ops-zeroconf-goals-01.txt 877 - Scope of document has been restricted to the 3GPP deployment 878 environment. 880 13. Informative References 882 [1] Nordmark, E., Basic Transition Mechanisms for IPv6 Hosts and 883 Routers, draft-ietf-v6ops-mech-v2-04.txt (work in progress), 884 July 2004. 885 [2] Lind, M., Scenarios and Analysis for Introducing IPv6 into ISP 886 Networks, draft-ietf-v6ops-isp-scenarios-analysis-03.txt (work 887 in progress), June 2004. 888 [3] Huitema, C., Evaluation of Transition Mechanisms for Unmanaged 889 Networks, draft-ietf-v6ops-unmaneval-03.txt (work in progress), 890 June 2004. 891 [4] Wiljakka, J., Analysis on IPv6 Transition in 3GPP Networks, 892 draft-ietf-v6ops-3gpp-analysis-10.txt (work in progress), May 893 2004. 894 [5] Durand, A., Requirements for assisted tunneling, draft-ietf- 895 v6ops-assisted-tunneling-requirements-00.txt (work in progress), 896 June 2004. 898 [6] Palet, J., Analysis of IPv6 Tunnel End-point Discovery 899 Mechanisms, draft-palet-v6ops-tun-auto-disc-01.txt (work in 900 progress), June 2004. 901 [7] Wasserman, M., Recommendations for IPv6 in 3GPP standards, RFC 902 3314. 903 [8] Loughney, J., IPv6 Node Requirements, draft-ietf-ipv6-node- 904 requirements-10.txt (work in progress), August 2004. 905 [9] IAB, IESG, IAB/IESG Recommendations on IPv6 Address Allocations 906 to Sites, RFC 3177. 907 [10] Savola, P., Security Considerations for 6to4, draft-ietf-v6ops- 908 6to4-security-04.txt (work in progress), July 2004. 909 [11] Nikander, P., IPv6 Neighbor Discovery (ND) Trust Models and 910 Threats, RFC 3756. 911 [12] Narten, T., Privacy Extensions for Stateless Address 912 Autoconfiguration in IPv6, RFC 3041. 913 [13] Narten, T., Neighbor Discovery for IP Version 6 (IPv6), RFC 914 2461. 915 [14] Jordi, P., draft-palet-v6ops-solution-tun-auto-disc-00 (work in 916 progress), September 2004. 918 Appendix A Out of Scope 920 [Editor's Note: This appendix can be removed in a future revision of 921 this document] 923 The following issues have been considered as being out of scope of 924 this work. 926 Mobile IPv6: 928 Support of Mobile IPv6 usage over the tunnel-link; here under 929 potential mechanisms required to support MIPv6 movement detection as 930 well as fast tunnel set-up for Mobile IPv6 session survivability. 932 Intellectual Property Statement 934 The IETF takes no position regarding the validity or scope of any 935 Intellectual Property Rights or other rights that might be claimed to 936 pertain to the implementation or use of the technology described in 937 this document or the extent to which any license under such rights 938 might or might not be available; nor does it represent that it has 939 made any independent effort to identify any such rights. Information 940 on the IETF's procedures with respect to rights in IETF Documents can 941 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 943 Copies of IPR disclosures made to the IETF Secretariat and any 944 assurances of licenses to be made available, or the result of an 945 attempt made to obtain a general license or permission for the use of 946 such proprietary rights by implementers or users of this 947 specification can be obtained from the IETF on-line IPR repository at 948 http://www.ietf.org/ipr. 950 The IETF invites any interested party to bring to its attention any 951 copyrights, patents or patent applications, or other proprietary 952 rights that may cover technology that may be required to implement 953 this standard. Please address the information to the IETF at ietf- 954 ipr@ietf.org. 956 Copyright Statement 958 Copyright (C) The Internet Society (2004). This document is subject 959 to the rights, licenses and restrictions contained in BCP 78, and 960 except as set forth therein, the authors retain all their rights. 962 Disclaimer of Validity 964 This document and the information contained herein are provided on an 965 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 966 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 967 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 968 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 969 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 970 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 972 This Internet-Draft expires April 4, 2005.