idnits 2.17.1 draft-nielsen-v6ops-zeroconf-goals-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 925. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 909. ** 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? == 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 (September 2, 2004) is 7177 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: 8 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Nielsen 2 INTERNET-DRAFT Ericsson 3 M. Morelli 4 Expires: March 2, 2005 Telecom Italia Lab 5 J. Palet 6 Consulintel 7 J. Soininen 8 Nokia 9 J. Wiljakka 10 Nokia 12 September 2, 2004 14 Goals for Zero-Configuration Tunneling 15 17 Status of this memo 19 By submitting this Internet-Draft, I certify that any applicable 20 patent or other IPR claims of which I am aware have been disclosed, 21 and any of which I become aware will be disclosed, in accordance with 22 RFC 3668 (BCP 79). 24 By submitting this Internet-Draft, I accept the provisions of Section 25 [#3] of RFC 3667 (BCP 78). 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that other 29 groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or cite them other than as "work in progress". 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/lid-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Abstract 44 This document describes the set of goals to be fulfilled by a Zero- 45 Configuration Tunneling protocol. 47 Zero-Configuration Tunneling here denotes a minimalistic IPv6-in-IPv4 48 automatic tunneling mechanism that could be used by a Service 49 Provider to offer IPv6 connectivity to its customers in early phases 50 of IPv4 to IPv6 transition. 52 Table of Contents 54 1. Introduction.....................................................2 55 2. Terminology......................................................4 56 3. Scope and Limitations............................................4 57 3.1. IPv6 address allocation, Scope and Limitations:.............4 58 3.2. IPv6 tunnel link characteristics, Scope and Limitations:....5 59 4. Assumptions and Prerequisites....................................5 60 4.1. Applicability Assumptions...................................5 61 4.2. 3GPP Compliance Prerequisite................................6 62 5. Timing...........................................................6 63 6. Goals............................................................7 64 6.1. Simplicity..................................................7 65 6.2. Automated IPv6-in-IPv4 tunnel establishment.................7 66 6.3. Use native when available...................................7 67 6.4. Easy to deploy and Easy to Phase-out with no modifications on 68 existing equipment...............................................8 69 6.5. Tunnel Server End-point Discovery...........................8 70 6.6. Address Assignment..........................................8 71 6.7. Tunnel Link Sustainability..................................9 72 6.8. Tunnel End-Point Reachability Detection.....................9 73 6.9. Private and public IPv4 addresses...........................9 74 6.10. Scalability, Load Balancing................................9 75 6.11. Security..................................................10 76 7. Non Goals.......................................................10 77 7.1. NAT and Firewall Traversal.................................10 78 7.2. IPv6 DNS...................................................10 79 7.3. Extensibility..............................................11 80 7.4. Registration burden........................................11 81 8. Stateful or Stateless...........................................11 82 9. Security Considerations.........................................11 83 9.1. Threats to existing network infrastructures................12 84 9.2. Threats to nodes implementing Zero-Configuration Tunneling.12 85 9.2.1. Threats to end-hosts..................................13 86 9.2.2. Threats to Tunnel Servers.............................13 87 9.2.2.1. Tunnel State related risks.......................13 88 9.2.2.2. Traffic related risks............................14 89 9.2.2.3. Packet Delivery related threats..................14 90 9.3. Implications of Direct Tunneling...........................14 91 10. Acknowledgments................................................15 92 11. Authors Addresses..............................................15 93 12. Changes from draft-nielsen-v6ops-zeroconf-goals-00.txt.........16 94 13. Informative References.........................................17 95 Appendix A Out of Scope............................................18 96 Appendix B Open Issues.............................................18 98 1. Introduction 99 The IETF v6ops Working Group has identified and analyzed deployment 100 scenarios for IPv4/IPv6 transition mechanisms in various stages of 101 IPv6 deployment and IPv6 and IPv4 coexistence. 103 This work has been carried out for a number of different network 104 environments each with their particular characteristics: Enterprise, 105 ISP, Unmanaged and 3GPP networks, see e.g., [2], [3] and [4]. 107 The work has identified a need for automatic IPv6-in-IPv4 tunneling 108 mechanisms that provide bidirectional IPv6-in-IPv4 tunneled 109 connectivity between dual stack end-nodes located at an IPv4-only 110 access network and dual-stack tunnel servers located at IPv6-IPv4 111 network boundaries within the Service Providers network. 113 The term Zero-Configuration Tunneling is used in this document to 114 denote an IPv6-in-IPv4 tunneling mechanism that fulfills the goals as 115 put forward here. 117 A Zero-Configuration Tunneling mechanism provides a basic set of 118 tunneling features only, and intentionally so. The scope of Zero- 119 Configuration Tunneling is not to provide emulation of the full suite 120 of native IPv6 connectivity functions as defined by [7], [8] and [9]; 121 rather the focus is to provide a minimal set of features required for 122 automatic establishment of IPv6 connectivity. 124 The starting point for the definition of the set of goals to be 125 fulfilled by a Zero-Configuration Tunneling mechanism has been the 126 set of features required for the IPv6-in-IPv4 tunneling mechanism 127 envisaged to be needed during the early phases of IPv6 transition in 128 3GPP environments as described in [4]. 130 The applicability of Zero-Configuration Tunneling may widen to other 131 transition scenarios. 133 For scenarios demanding advanced tunneling features, for example full 134 emulation of native (though tunneled) IPv6 connectivity, a more full- 135 fledged tunneling mechanism is envisaged to be deployed, see [5]. 136 With respect to the latter, an analysis of appropriate mechanisms for 137 automatic discovery of the tunnel endpoint is being done in [6]. 139 It should be emphasized that unless otherwise specified then in this 140 document the reference, IPv6-in-IPv4 encapsulation as defined in [1], 141 refers to the aspects of Protocol-41 encapsulation related to IPv4 142 header construction (except for source and destination address 143 determination), MTU and Fragmentation, Hop Limits and ICMP handling 144 as detailed in Section 3.1-3.6 of [1]. The particular aspects of 145 Configured IPv6-In-IPv4 Tunneling in the areas of IPv4 source and 146 destination address determination, tunnel link characteristics and 147 IPv6 Neighbor Discovery operation are not intended referred to by the 148 above reference. 150 2. Terminology 152 Zero-Configuration Tunneling site: 153 A logical IPv4 network over which IPv6 connectivity is provided to 154 dual-stack nodes by means of Zero-Configuration Tunneling. 156 Tunnel End-point: 157 A dual-stack node performing IPv6-in-IPv4 tunnel 158 encapsulation/decapsulation in accordance with Zero-Configuration 159 Tunneling. 161 Tunnel Server: 162 A dual-stack server node with IPv6 connectivity and which provides 163 IPv6 connectivity to client nodes by performing IPv6-in-IPv4 tunnel 164 encapsulation/decapsulation to/from client nodes in accordance with 165 Zero-Configuration Tunneling. 167 A Tunnel Server is likely to be a dual-stack router. 169 Tunnel Client: 170 A dual-stack node that obtains IPv6 connectivity by means of Zero- 171 Configuration Tunneling. A tunnel client relies on IPv6-in-IPv4 172 tunnel encapsulation/decapsulation to/from Tunnel Servers for IPv6 173 communications to native IPv6 nodes. 175 Direct Tunneling: 176 Direct tunnelling here refer to the case where end-hosts located 177 within the same Zero-Configuration Tunnelling site may circumvent the 178 Tunnel Server and communicate directly using the tunnel protocol. 180 3. Scope and Limitations 182 The scope of Zero-Configuration Tunneling is restricted to an 183 absolute minimal set of functions required to provide automatic IPv6 184 connectivity establishment to dual stack nodes by means of IPv6-in- 185 IPv4 encapsulation as defined in [1] to tunnel servers under the 186 assumptions and prerequisites described in Section 4. 188 Zero-Configuration Tunneling does not attempt to provide emulation of 189 the full set of native IPv6 connectivity functions as defined by [7], 190 [8] and [9]. 192 3.1. IPv6 address allocation, Scope and Limitations: 194 The primary goal of Zero-Configuration Tunneling is to provide IPv6 195 connectivity to nodes on an individual basis. By this it is meant 196 that it is only an explicit goal to have a /128 address allocated for 197 global connectivity on the tunnel link. As such optimal IPv6 198 connectivity provisioning in Personal Area Network (PAN) scenarios is 199 not explicitly within the scope of Zero-Configuration Tunneling. 201 It is not explicitly within the scope of Zero-Configuration Tunneling 202 to support usage of privacy IPv6 extensions as defined in [12]. 204 It is not explicitly within the scope to support usage of IPv6 205 multicast. 207 No goals are defined as to how address configuration should be 208 performed. This may be done based on legacy stateless or stateful 209 IPv6 address configuration mechanisms or by some altogether different 210 mechanism particular to the zero-configuration solution. 212 3.2. IPv6 tunnel link characteristics, Scope and Limitations: 214 Direct tunneling is neither an explicit goal nor explicitly excluded 215 in Zero-Configuration Tunneling. 217 It is not an explicit requirement for the zero-configuration tunnel 218 link to support IPv6 link-local multicast. 220 The tunnel protocol should allow for the formation of a link-local 221 address on the tunnel link. Though no particular usage of such an 222 address is explicitly demanded by the goals set forward here. 224 It is an explicit goal that nodes attached to a tunnel link must be 225 able to ascertain the reachability of neighbors with which it is 226 communicating (or wish to start communicate). This may be achieved 227 using IPv6 Neighbor Discovery mechanism ([13]) based on unicast link- 228 local packet exchanges (or link-local multicast if such is supported) 229 but it may also be achieved by altogether different mechanisms. 231 4. Assumptions and Prerequisites 233 4.1. Applicability Assumptions 235 Zero-Configuration Tunneling is a tunneling mechanism by the virtue 236 of which dual-stacks hosts, attached to IPv4-only networks links, can 237 use IPv6-in-IPv4 encapsulation as defined in [1] to tunnel servers 238 for global IPv6 connectivity. 240 The aim of the document is to define the set of goals to be fulfilled 241 by zero-configured tunneling when the following assumptions are made 242 on the deployment environment: 244 - IPv4 source addresses spoofing within the Zero-Configuration 245 Tunneling site is prevented. 246 - The Zero-Configuration Tunneling site is protected from proto-41 247 encapsulated packets arriving from external IPv4 networks. 249 - At least one authoritative DNS server is IPv4-enabled and at 250 least one recursive DNS server supports IPv4. Further IPv4 DNS 251 Server discovery is provided by already existing means/means 252 outside the scope of the tunnel protocol. 253 - There are no NATs in between the tunnel endpoints in the Zero- 254 Configuration Tunneling site. 255 - The Zero-Configuration Tunneling network is fully penetrable for 256 intra-site IPv6-in-IPv4 Protocol 41 traffic. 257 - The user is being authenticated to the network by means external 258 to the tunneling protocol and other than that no additional 259 authentication/registration mechanisms are required. 261 The above assumptions are believed to be readily applicable to the 262 3GPP tunneling transition scenario described in [4], section 3.1. 264 It is a prerequisite that the tunnel protocol must work in IPv4 265 network environments where IPv4 multicast is not provided. 267 4.2. 3GPP Compliance Prerequisite 269 It is a prerequisite that Zero-Configuration Tunneling should be 270 applicable in 3GPP wireless networks. When considering the 271 characteristics of 3GPP network links and mobile terminals / User 272 Equipment (UE), the following points need to be taken into account: 273 - Link bandwidth (tunnel overhead / usage cost) 274 - Link latency 275 - UE battery power and derived implications on memory and 276 processing power 278 It is thus an explicit requirement for Zero-Configuration Tunneling 279 to comply well with the constrained conditions put on the above 280 parameters by the 3GPP environments. The latter which commonly is 281 recognized as translating into requirements for the protocol to 282 operate with a limited number of message exchanges, small packet 283 sizes and simple message processing. 285 Here we shall refer to a protocol as being lightweight when its 286 demands on message exchanges, packet sizes and message processing 287 complexity are sufficiently light for it to be readily applicable in 288 environments characterized by the constrained conditions of 3GPP 289 networks (as described above). 291 As a mean to ensure that the protocol be lightweight it is considered 292 preferable for the protocol to provide a simple set of functions 293 only, even if it provides only a basic IPv6 service compared to the 294 native one. It is although acknowledged that additional functionality 295 doesn't necessarily automatically add complexity to the demands on 296 the aforementioned parameters. 298 5. Timing 299 For the purpose of 3GPP deployment it is a prerequisite that this 300 tunneling protocol is provided within a very restrictive timescale. 302 Zero-Configuration Tunneling is envisaged to be deployed in 3GPP 303 networks as an initial and temporary mechanism to provide limited 304 IPv6 connectivity services. Native IPv6 like connectivity is in 3GPP 305 environments envisaged to be feasible by virtue of true native IPv6 306 only. 308 Trial deployments, in which zero-configuration type of IPv6 309 connectivity is provided in 3GPP environments, are starting up using 310 experimental protocols at the time of writing this document. 312 6. Goals 314 The goals to be achieved by Zero-Configuration Tunneling are detailed 315 in the following subsections. 317 6.1. Simplicity 319 By simplicity, we understand a tunnel protocol that is easy to 320 implement in the targeted environment. Additionally, the protocol 321 should provide a reasonable, limited set of basic IPv6 connectivity 322 features. 324 Further by simplicity we imply that the protocol must be lightweight. 326 6.2. Automated IPv6-in-IPv4 tunnel establishment 328 The protocol should provide for the set up of IPv6-in-IPv4 tunnels, 329 based on IPv6-in_IPv4 encapsulation as defined in [1], from dual- 330 stack nodes, attached to IPv4-only networks, to Tunnel Servers. 332 The IPv6-in-IPv4 tunnels and the IPv6 connectivity must be 333 established in an automated manner, i.e. without requiring manual 334 intervention at any of the tunnel end-points at tunnel establishment 335 time. 337 The mechanism must be fully dynamic in the sense that it must not 338 require IP address information such as the IPv4 address of a Tunnel 339 Server and/or the IPv6 address(es) to use for IPv6 connectivity to be 340 configured on the Tunnel Clients beforehand. 342 6.3. Use native when available 344 The tunnel protocol should allow the usage of native IPv6 345 connectivity whenever such is available. 347 The protocol must in no way restrict the native IPv6 capabilities of 348 the client node. 350 The node should not use Zero-Configuration Tunneling when native IPv6 351 connectivity is available. 353 Comment: The fact that a node should not use Zero-Configuration 354 Tunneling when native IPv6 connectivity is available is not 355 considered to be a functional requirement on the tunnel protocol. 356 Rather it is considered related to when, and how, the node 357 (implementation) uses the Zero-Configuration Tunneling function. 359 6.4. Easy to deploy and Easy to Phase-out with no modifications on 360 existing equipment 362 The tunnel protocol should be easy to deploy into the existing IPv4 363 and IPv6 network infrastructure. 365 The tunnel protocol should have no major impact on protocols and 366 infrastructure nodes deployed in existing infrastructures providing 367 IPv4 and native IPv6 connectivity. 369 The tunnel protocol should coexist and work seamlessly together with 370 any native IPv6 infrastructure that gradually may be implemented in 371 the network. The tunnel protocol should have no negative implications 372 on how such are implemented. 374 The tunnel protocol must be easy to take out of service once native 375 IPv6 is available. 377 6.5. Tunnel Server End-Point Auto-Discovery 379 The tunnel protocol must provide a mechanism for automated end-point 380 discovery by the virtue of which end-hosts automatically and at run- 381 time can determine the IPv4 addresses of available Tunnel Servers. 383 The discovery mechanism should rely on intrinsic services, read 384 services already universally deployed, to the particular network 385 environment. It should not require the addition of additional IP 386 network infrastructure elements for this function only. 388 Comment: The analysis done in [6] may apply. 390 6.6. Address Assignment 392 The tunnel protocol must allow for the assignment of at least one 393 globally routable (/128) IPv6 unicast address to use for tunneled 394 IPv6 connectivity over the link provided by the Zero-Configuration 395 Tunneling mechanism. 397 It is preferable that the address assignment provides a stable 398 address, that is, an address that can be used for IPv6 connectivity 399 for a certain amount of time rather than solely one address per 400 higher layer session initiation. 402 6.7. Tunnel Link Sustainability 404 The tunnel link established in between a host deploying Zero- 405 Configuration Tunneling and an associated Tunnel Server should be 406 expected to remain in administrative active state for the lifetime of 407 the IPv6 address provided to the host. 409 The tunnel protocol must not mandate keep-alive messages to be 410 transmitted by the host simply in order to sustain tunnel link 411 connectivity. 413 Motivation: The fact that a 3GPP terminal, for the single purpose of 414 transmitting keep-alive messages, could have to wake up the radio 415 periodically, send a packet over the radio and possibly wait for 416 response is undesirable for the following reasons: 417 - The terminal cannot, as otherwise anticipated, be in dormant 418 mode all the time it is idle. This has severe implications for 419 the battery consumption of the device. 420 - Radio resources are costly and sparse and consequently not to be 421 used for what is considered to be unnecessary traffic. 423 6.8. Tunnel End-Point Reachability Detection 425 The tunnel protocol must allow for means for one tunnel end-point to 426 verify the reachability of other tunnel end-points towards which it 427 intends to send packets. 429 The unicast neighbor reachability discovery functions provided by 430 IPv6 Neighbor Discovery ([13]), i.e., unicast NS/NA exchanges, should 431 be supported on the tunnel link. 433 6.9. Private and public IPv4 addresses 435 The tunnel protocol must work over IPv4 sites deploying both private 436 and public IPv4 addresses. 438 Furthermore, the tunnel protocol should work with both dynamic and 439 static IPv4 address allocation. 441 Motivation: Private IPv4 addresses are widely used in current 3GPP 442 networks. 444 6.10. Scalability, Load Balancing 446 In order to ensure the scalability of the tunnel service, in terms of 447 not limiting the number of simultaneous connections to the service 448 and consequently limiting possible service denial situations, it 449 should be possible for a Service Provider to load-balance those 450 connections among several available Tunnel Servers. 452 Load balancing should be planned already during the early phases of 453 deployment. Given adequate planning it should be possible for a 454 Service Provider to seamlessly deploy additional Tunnel Servers in 455 order to support an increased amount of Tunnel Clients. 457 Comment: This may be achieved using load balancing functions provided 458 by the Tunnel Server End-point Discovery mechanism as detailed in 459 [14]. 461 6.11. Security 463 The tunnel protocol should not impose any new vulnerability to the 464 existing network infrastructure. 466 The tunnel protocol should not impose any new vulnerability to the 467 nodes implementing the tunnel protocol than what is already present 468 in existing multi-access IPv6 networks, where multiple hosts are 469 served by the same router or possibly multiple routers. 471 7. Non Goals 473 Non-goals of zero-configured tunneling are detailed in the following 474 subsections. 476 With the term Non-goals we refer to features that generally are 477 believed to be applicable to tunneling, but which are not among the 478 minimal set of required features of Zero-Configuration Tunneling. The 479 latter primarily because of the prerequisites for Zero-Configuration 480 Tunneling and/or because of the assumptions made on the applicability 481 environments for Zero-Configuration Tunneling, e.g., see Section 4. 483 7.1. NAT and Firewall Traversal 485 NAT and Firewall traversal is not required due to the assumptions on 486 the applicability environment. 488 Moreover to minimize the tunneling overhead applied to the packets as 489 well as in order to minimize the number of tunnel set-up signaling 490 messages exchanged on the link, it is preferable that the protocol 491 does not deploy the UDP encapsulation techniques, on which mechanisms 492 able to traverse NATs and Firewalls normally rely. 494 7.2. IPv6 DNS 496 By virtue of the assumptions on the applicability environments, the 497 dual stack end-hosts can use IPv4 DNS discovery mechanisms and IPv4 498 transport for DNS services. 500 Given that IPv4 based DNS services are already available, it is not 501 considered a requirement that the end-host should be able to deploy 502 IPv6 based DNS services. Consequently, the tunnel protocol does not 503 need to provide IPv6 DNS discovery mechanisms. 505 7.3. Extensibility 507 As a minimal tunneling mechanism Zero-Configuration Tunneling targets 508 IPv6 connectivity provisioning only. The protocol does not need to be 509 readily extendable to other encapsulation mechanisms, e.g., IPv4-in- 510 IPv6. 512 7.4. Registration burden 514 Tunnel service registration is not required due to the assumptions on 515 the applicability environment. 517 In order to keep the simplicity and minimize the tunnel overhead it 518 is desirable that the tunnel protocol not in itself (e.g., in order 519 to meet the goals put forward in this document) mandates 520 authenticated registration of the user. 522 8. Stateful or Stateless 524 By a stateful mechanism we mean a mechanism that require the Tunnel 525 Server to maintain tunnel state per client it serves. 527 Tunnel state here is considered to be any parameter kept by the 528 server per client and without which the server is unable to serve the 529 client (receive packets from/send packets to). 531 Tunnel state must be distinguished from state used to optimize the 532 packet delivery function of the tunnel server and which is kept in a 533 fixed or upper limited amount of memory space, such as, e.g., 534 reachability information. 536 It should be emphasized that this document makes no deliberate 537 assumptions on whether a Zero-Configuration Tunneling solution should 538 be based on a stateful or stateless Tunnel Server mechanism. Indeed 539 it is anticipated that the goals of zero-configuration as put forward 540 here could be served both by a stateless as well as by a stateful 541 mechanism. 543 9. Security Considerations 545 It is assumed that the following assumptions of Section 4 are valid 546 in the particular network environment: 548 - IPv4 source addresses spoofing within the Zero-Configuration 549 Tunneling site is prevented. 550 - The Zero-Configuration Tunneling site is protected from proto-41 551 encapsulated packets arriving from external IPv4 networks. 553 It is worthwhile to note that together these assumptions imply that 554 the IPv4 source of all protocol-41 tunneled packets is legitimate. 556 9.1. Threats to existing network infrastructures 558 As stated in Section 6.11 the tunnel protocol should not impose any 559 new vulnerability to the existing network infrastructure. 561 The following have been identified as potential threats opened up for 562 by the deployment of Zero-Configuration Tunneling: 564 - As the tunnel service is un-authenticated (not registered) it 565 may be possible to use a tunnel server to reflect tunneled 566 packets into the network, similar to the 6to4-reflection attacks 567 identified in [10]. 568 - The Zero-configuration site must be kept fully penetrable for 569 intra-site IPv6-in-IPv4 protocol-41 encapsulated packets. This 570 may open up for threats to end-hosts that rely on the network 571 infrastructure to filter out bogus protocol-41 encapsulated 572 packets. 573 - Zero-configuration tunneling may open up for threats to other 574 mechanisms in the network that rely on Protocol-41 575 encapsulation. 577 Detailed analysis of the validity of these threats will have to 578 depend on the particular zero-configuration solution. In general it 579 could be noted that attacks based on the above threats largely should 580 be preventable if the end-hosts in the network implement appropriate 581 drop policies, either simple drop all protocol-41 policies or more 582 differentiated policies based, e.g., on source addresses. 584 9.2. Threats to nodes implementing Zero-Configuration Tunneling 586 The following considerations apply to the situation where Zero- 587 Configuration Tunneling is deployed in between tunnel servers and 588 end-hosts only. 590 Special security considerations for the usage of Zero-Configuration 591 Tunneling for direct tunneling in between end-hosts is given in 592 Section 9.3. 594 As stated in Section 6.11 the tunnel protocol should not impose any 595 new vulnerability to the nodes implementing the tunnel protocol than 596 what is already present in existing multi-access IPv6 networks where 597 multiple hosts are served by the same router or possible multiple 598 routers. 600 Here it is implicitly assumed that the tunnel server(s) take the role 601 of default routers and the end-nodes using Zero-Configuration 602 Tunneling for IPv6 connectivity the role of hosts in multi-access 603 environments. 605 9.2.1. Threats to end-hosts 607 Given that all IPv4 sources of protocol-41 tunneled packets can be 608 assumed to be legitimate, threats stemming from encapsulated packets 609 sourced by nodes (addresses) other than nodes (addresses) which the 610 end-hosts recognize as tunnel servers (identified by addresses) can, 611 if not already an intrinsic part of the zero-configuration protocol, 612 easily be mitigated by the implementation of appropriate 613 differentiated (source addresses) drop policies in the end-hosts, 614 i.e., accept only if source is tunnel server. 616 In current multi-access IPv6 networks hosts need to trust on the 617 benevolence of their default routers as well as hosts must trust that 618 anyone impersonating as a router is indeed one, see, e.g., the trust 619 models and threats described in [11]. 621 Future multi-access IPv6 networks may rely on SEND mechanisms, i.e., 622 mechanisms developed in the SEND WG in order to mitigate the threats 623 described in [11], to establish a trust relations ship in between 624 host and routers. 626 Given that IPv4 source address spoofing is not possible in Zero- 627 Configuration Tunneling sites, then 628 - for an end-host to trust that packets it perceives as stemming 629 from tunnel servers do actually stem from such - as well as � 630 - for an end-host to trust on the benevolence of its tunnel 631 servers, 632 it suffices that a trustworthy tunnel server end-point discovery 633 mechanism, read discovery of benevolent tunnel servers IPv4 634 address(es), is implemented. 636 In open environments, such as, e.g., the 3GPP environment, it is 637 assumed a prerequisite that a trustworthy zero-configuration tunnel 638 server end-point discovery mechanism is implemented. 640 9.2.2. Threats to Tunnel Servers 642 Zero-Configuration Tunneling may be deployed over very large IPv4 643 sites with low density of active tunnel clients but with a very high 644 number of dormant, but potential tunnel clients. Therefore Denial of 645 Service prevention by strict over provisioning of Tunnel Server 646 capacity is unlikely to be performed. 648 9.2.2.1. Tunnel State related risks 650 If the Tunnel Server relies on state to be kept per tunnel client 651 that it serves, the server risks resource exhaustion. 653 In this situation it is a security prerequisite that no node, whether 654 located within or outside the Zero-Configuration Tunneling site, can 655 initiate initialization of tunnel state for other entities than 656 itself. 658 Given this prerequisite, then for tunnel server resource exhaustion 659 by tunnel state creation to be categorized as a security threat, 660 rather than a case of under provisioning, requires a large number of 661 tunnel clients to operate in co-action. This is thus not considered a 662 plausible threat. 664 9.2.2.2. Traffic related risks 666 Tunnel encapsulation is recognized as being more resource demanding 667 than mere packet forwarding. Given the same traffic load a Tunnel 668 Server must thus be more generously provisioned that a corresponding 669 router for it not to be more likely to get overthrown by large 670 unexpected amounts of traffic than the router. 672 The authors have found no plausible treats to the tunnel service, due 673 to large unexpected amounts of traffic needing encapsulation, which 674 can be classified as a security threat rather than a case of under 675 provision. This regardless of whether the traffic is due to a surge 676 in the density of active tunnel clients or due to a surge in the 677 traffic streams set-up by active clients. 679 9.2.2.3. Packet Delivery related threats 681 One potential risk related to packet delivery has been identified. 682 This risk is the equivalent of the threat to routers in multi-access 683 environments described in [11], Section 4.3.2. 685 The risk is associated with the special case where the tunnel 686 protocol requires special resource demanding and/or temporary state 687 creation actions to be taken by the Tunnel Server for delivery of 688 packets destined for not recently addressed Tunnel Clients. The 689 situation where such actions must be performed for all packets at all 690 times is considered to be unlikely. The actions required could be 691 buffering of packets while the reachability of the destined node is 692 being verified. 694 In case a malicious node (located either within or outside the zero- 695 configuration site) is able to continuously send packets to 696 continuously changing nodes, which by the Tunnel Server is perceived 697 as being existing or potential client nodes, the malicious node may 698 be able to exhaust the Tunnel Servers capability of delivering 699 packets by saturating the packet buffering mechanism and the 700 reachability state table as well as by keeping the Tunnel Server busy 701 determining the reachability state of the ever changing client nodes. 703 9.3. Implications of Direct Tunneling 704 In case direct tunneling in between end-hosts is provided by the 705 tunneling protocol, it will not (as described in Section 9.2.1) be 706 possibly for end-hosts to filter out received Protocol-41 707 encapsulated packets based on whether the IPv4 source is an address 708 belonging to a trusted Tunnel Server as such behavior evidently would 709 break direct tunneling. 711 As other end-hosts generally are non-trusted, direct tunneling may 712 thus open up for attacks against IPv6 ingress filtering. 714 Detailed analysis of the validity of this threat will have to depend 715 on the particular zero-configuration solution. 717 10. Acknowledgments 719 Prior work by J. Mulahusic on the requirements for UE tunneling has 720 been considered in the initial stage of the work. 722 This work has benefited from input and comments provided by Fred 723 Templin in the initial phase of the work. 725 Thanks are due to Pekka Savola for many helpful comments and 726 suggestions for improvements. 728 Corresponding work on assisted-tunneling, [5], has been an 729 inspiration for the Zero-Configuration Tunneling work. 731 The authors would like to acknowledge the European Commission support 732 in the co-funding of the Euro6IX project, where part of this work is 733 being developed. 735 11. Authors Addresses 737 Mario Morelli 738 Telecom Italia Lab. 739 Via Guglilmo Reiss Romoli, 274 740 I-10148 Turin, 741 Italy 743 Phone: +39 011 228 7790 744 Fax: +39 011 228 5069 745 Email: mario.morelli@tilab.com 747 Karen Egede Nielsen 748 Ericsson 749 Skanderborgvej 232 750 8260 Viby J 751 Denmark 752 Phone: + 45 89 38 51 00 753 Email: karen.e.nielsen@ericsson.com 755 Jordi Palet Martinez 756 Consulintel 757 San Jose Artesano, 1 758 Alcobendas - Madrid 759 E-28108 - Spain 761 Phone: +34 91 151 81 99 762 Fax: +34 91 151 81 98 763 EMail: jordi.palet@consulintel.es 765 Jonne Soininen 766 Nokia 767 Linnoitustie 6 768 02600 ESPOO 769 Finland 771 Phone: +358 7180 08000 772 EMail: jonne.soininen@nokia.com 774 Juha Wiljakka 775 Nokia 776 Visiokatu 3 777 33720 TAMPERE 778 Finland 780 Phone: +358 7180 48372 781 EMail: juha.wiljakka@nokia.com 783 12. Changes from draft-nielsen-v6ops-zeroconf-goals-00.txt 785 - Aimed to clarify what is meant by full suite of native Ipv6 786 connectivity functions. 788 - Aimed to clarify what is meant when referring to IPv6-in-IPv4 789 encapsulation as defined in [1]. 791 - Aimed to clarify the accepted limitations of the IPv6 792 connectivity service provided by Zero-Configuration Tunneling 793 compared to the full suite of native IPv6 795 - Added that it is a prerequisite that Zero-Configuration 796 Tunneling can work over IPv4 networks where Ipv4 multicast is 797 not supported. 799 - Clarified goal, Section 6.3, on usage of native IPv6 when 800 available. 802 - Added goal on load sharing and scalability, Section 6.10. 804 - Added Section 8, discussing state or no state. 806 - Changed Section 6.8 on reachability detection to refer to 807 unicast Neighbor Discovery techniques rather than IPv6 NUD. 809 - Added material to the section on threats to tunnel servers, 810 9.2.2. 812 - Added section, Section 9.3, discussing particular security 813 considerations for usage of direct tunneling. 815 - Added text under Acknowledgements 817 - Specified references as informative. 819 - Performed various Editorial changes. 821 13. Informative References 823 [1] Nordmark, E., Basic Transition Mechanisms for IPv6 Hosts and 824 Routers, draft-ietf-v6ops-mech-v2-04.txt (work in progress), 825 July 2004. 826 [2] Lind, M., Scenarios and Analysis for Introducing IPv6 into ISP 827 Networks, draft-ietf-v6ops-isp-scenarios-analysis-03.txt (work 828 in progress), June 2004. 829 [3] Huitema, C., Evaluation of Transition Mechanisms for Unmanaged 830 Networks, draft-ietf-v6ops-unmaneval-03.txt (work in progress), 831 June 2004. 832 [4] Wiljakka, J., Analysis on IPv6 Transition in 3GPP Networks, 833 draft-ietf-v6ops-3gpp-analysis-10.txt (work in progress), May 834 2004. 835 [5] Durand, A., Requirements for assisted tunneling, draft-ietf- 836 v6ops-assisted-tunneling-requirements-00.txt (work in progress), 837 June 2004. 838 [6] Palet, J., Analysis of IPv6 Tunnel End-point Discovery 839 Mechanisms, draft-palet-v6ops-tun-auto-disc-01.txt (work in 840 progress), June 2004. 841 [7] Wasserman, M., Recommendations for IPv6 in 3GPP standards, RFC 842 3314. 843 [8] Loughney, J., IPv6 Node Requirements, draft-ietf-ipv6-node- 844 requirements-10.txt (work in progress), August 2004. 846 [9] IAB, IESG, IAB/IESG Recommendations on IPv6 Address Allocations 847 to Sites, RFC 3177. 848 [10] Savola, P., Security Considerations for 6to4, draft-ietf-v6ops- 849 6to4-security-04.txt (work in progress), July 2004. 850 [11] Nikander, P., IPv6 Neighbor Discovery (ND) Trust Models and 851 Threats, RFC 3756. 852 [12] Narten, T., Privacy Extensions for Stateless Address 853 Autoconfiguration in IPv6, RFC 3041. 854 [13] Narten, T., Neighbor Discovery for IP Version 6 (IPv6), RFC 855 2461. 856 [14] Jordi, P., draft-palet-v6ops-solution-tun-auto-disc-00 (work in 857 progress), September 2004. 859 Appendix A Out of Scope 861 [Editor's Note: This appendix can be removed in a future revision of 862 this document] 864 The following issues have been considered as being out of scope of 865 this work. 867 DNS: 869 DNS registration of the IPv6 addresses allocated to dual stack nodes 870 while deploying Zero-Configuration Tunneling for IPv6 connectivity. 872 Mobile IPv6: 874 Support of Mobile IPv6 usage over the tunnel-link; here under 875 potential mechanisms required to support MIPv6 movement detection as 876 well as fast tunnel set-up for Mobile IPv6 session survivability. 878 Appendix B Open Issues 880 [Editor's Note: This appendix can be removed in a future revision of 881 this document] 883 Allow NATs that support proto-41 forwarding: 884 Should the no NATs assumption be relaxed to allow only NATs which 885 support proto-41 forwarding ? 887 Intellectual Property Statement 889 The IETF takes no position regarding the validity or scope of any 890 Intellectual Property Rights or other rights that might be claimed to 891 pertain to the implementation or use of the technology described in 892 this document or the extent to which any license under such rights 893 might or might not be available; nor does it represent that it has 894 made any independent effort to identify any such rights. Information 895 on the IETF's procedures with respect to rights in IETF Documents can 896 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 898 Copies of IPR disclosures made to the IETF Secretariat and any 899 assurances of licenses to be made available, or the result of an 900 attempt made to obtain a general license or permission for the use of 901 such proprietary rights by implementers or users of this 902 specification can be obtained from the IETF on-line IPR repository at 903 http://www.ietf.org/ipr. 905 The IETF invites any interested party to bring to its attention any 906 copyrights, patents or patent applications, or other proprietary 907 rights that may cover technology that may be required to implement 908 this standard. Please address the information to the IETF at ietf- 909 ipr@ietf.org. 911 Copyright Statement 913 Copyright (C) The Internet Society (2004). This document is subject 914 to the rights, licenses and restrictions contained in BCP 78, and 915 except as set forth therein, the authors retain all their rights. 917 Disclaimer of Validity 919 This document and the information contained herein are provided on an 920 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 921 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 922 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 923 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 924 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 925 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 927 This Internet-Draft expires March 2, 2005.