idnits 2.17.1 draft-savola-v6ops-conftun-setup-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Jan 2004) is 7401 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-01 ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '3') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (ref. '4') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (ref. '5') (Obsoleted by RFC 8415) == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-17 -- Obsolete informational reference (is this intentional?): RFC 2472 (ref. '10') (Obsoleted by RFC 5072, RFC 5172) == Outdated reference: A later version (-05) exists of draft-huitema-v6ops-teredo-00 == Outdated reference: A later version (-01) exists of draft-massar-v6ops-heartbeat-00 == Outdated reference: A later version (-05) exists of draft-ietf-grow-embed-addr-00 == Outdated reference: A later version (-03) exists of draft-thaler-ipv6-ndproxy-01 == Outdated reference: A later version (-11) exists of draft-ietf-v6ops-3gpp-analysis-07 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-unmaneval-00 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-isp-scenarios-analysis-00 Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force P. Savola 2 Internet-Draft CSC/FUNET 3 Expires: July 1, 2004 Jan 2004 5 Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP) 6 draft-savola-v6ops-conftun-setup-02.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at http:// 23 www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire on July 1, 2004. 30 Copyright Notice 32 Copyright (C) The Internet Society (2004). All Rights Reserved. 34 Abstract 36 This memo describes a set of operational procedures, a UDP 37 encapsulation for configured tunnels, and one implementation 38 mechanism to provide a very simple and straightforward way to easily 39 manage IPv6-over-IPv4 configured tunnels between an ISP and a 40 customer. The configured tunnels work even if the IPv4 addresses 41 change dynamically, or are private addresses; the procedure provides 42 at least a /64 prefix per customer and requires no administrative 43 set-up. A simple form of NAT traversal is also supported. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 49 2.1 Non-problems . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Overview of the Procedure . . . . . . . . . . . . . . . . . . 5 51 4. Customer-side Procedures . . . . . . . . . . . . . . . . . . . 6 52 4.1 Possible Prior Agreement with the ISP . . . . . . . . . . . . 6 53 4.2 Learning and Configuring the Tunnel Endpoint . . . . . . . . . 6 54 4.3 Tunnel Activation . . . . . . . . . . . . . . . . . . . . . . 7 55 4.4 Providing Connectivity to Other Nodes . . . . . . . . . . . . 7 56 5. ISP-side Procedures . . . . . . . . . . . . . . . . . . . . . 7 57 5.1 Possible Prior Agreements with the Customers . . . . . . . . . 8 58 5.2 Learning the Customers' Tunnel Endpoint Addresses . . . . . . 8 59 5.3 Prefix Advertisement or Delegation . . . . . . . . . . . . . . 9 60 5.4 Tunnel Activation and Maintenance . . . . . . . . . . . . . . 9 61 5.5 Secure Operations for Tunnel Service . . . . . . . . . . . . . 10 62 5.6 Sufficient Tunnel Service Provisioning . . . . . . . . . . . . 10 63 6. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 11 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 Normative References . . . . . . . . . . . . . . . . . . . . . 13 68 Informative References . . . . . . . . . . . . . . . . . . . . 13 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 70 A. Comparison to Other Mechanisms and Procedures . . . . . . . . 15 71 A.1 Configured Tunnels . . . . . . . . . . . . . . . . . . . . . . 15 72 A.2 L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 A.3 Tunnel Broker Solutions . . . . . . . . . . . . . . . . . . . 15 74 A.4 ISATAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 B. Multiple Users Behind a NATted IPv4 Address . . . . . . . . . 16 76 Intellectual Property and Copyright Statements . . . . . . . . 17 78 1. Introduction 80 A need for a simple mechanism to set up IPv6-over-IPv4 configured 81 tunnels between a customer and the ISP seems to have been 82 demonstrated in 3GPP analysis [17] as well as Unmanaged [18] and ISP 83 analysis [19]. Most currently proposed mechanisms (like 6to4 [7] or 84 ISATAP [8]) appear to be unnecessarily complex or otherwise 85 problematic in these particular scenarios. 87 ISPs that already have access infrastructure (L2TP Access 88 Concentrator (LAC), L2TP Network Servers (LNS), PPP Termination 89 Aggregators (PTA). etc.), IPv6/PPP/L2TP/UDP/IP could be readily 90 provided using L2TP [9] and IPv6 over PPP [10] as long as the 91 customer operating systems also support these mechanisms. This 92 approach, however, is not suitable for 3GPP and Enterprise 93 environments. See Appendix A for a more detailed comparison. 95 This memo documents a set of operational procedures which require no 96 additional protocol specification to provide a very simple and 97 suitably elegant solution to these problems. 99 One observation made prior to designing the procedure was that a 100 signalling protocol is not really needed if the existing mechanisms 101 for e.g., optional prefix delegation are used, and the ISP can 102 authenticate the user otherwise; this simplifies the procedure 103 significantly. 105 The second section gives a brief problem statement which also 106 describes the applicability of the solution. The third section 107 explains the overview of the procedure. The fourth and the fifth 108 sections describe the customer- and ISP-side procedures in more 109 detail. The sixth section describes issues related to a simple form 110 of NAT traversal, and specifies how to optionally encapsulate 111 IPv6-over-IPv4 packets over UDP. 113 In appendix A, we compare the mechanism to several other proposed 114 mechanisms and techniques: pure configured tunnels, the use of Layer 115 2 Tunneling Protocol (L2TP [9]), use of 6to4 [7], an instance of 116 Tunnel Broker concept -- TSP [11], ISATAP [8], and Teredo [12]. 118 2. Problem Statement 120 There are ISPs which are willing to provide IPv6 connectivity to 121 their customers, but may not be able to do it natively due to a 122 number of reasons. Such ISPs want to find a method to help in 123 providing IPv6-over-IPv4 tunnels to the customers, with the following 124 characteristics: 126 o The IPv4 address of the customer may be either static or dynamic, 127 and may be a private address [6] as well, if the customer chooses 128 to NAT the (public) IP address given by the ISP. 130 o The ISP may want to offer the tunnel service either requiring 131 prior agreement with the user, or to every customer who wishes to 132 try it. 134 o The customer may have one or more nodes which should obtain IPv6 135 connectivity. 137 o The configured tunnel may be set up either from the customer's 138 gateway, or if the gateway does not support IPv6, from a node 139 inside the customer's network, when NAT traversal is used. No 140 more than one node behind a NAT'ed public IPv4 address needs to 141 participate in the IPv4-in-IPv6 tunnel service (but many more can 142 use the IPv6 service, of course). 144 o The solution should be as simple as possible, requiring no new 145 protocols or substantial modifications to IPv6 or IPv4 146 implementations either at the ISP or customer side. 148 2.1 Non-problems 150 The problem statement explicitly excludes: 152 o Support for third party ISPs: the methods described here work to 153 an extent with a lower amount of security even if the ISP 154 providing the service is not the user's own ISP. Typically, the 155 third party ISP would have to be able to authenticate the user 156 somehow; this could be done using a static IPv4 address (rather 157 insecure), IPsec Security Association, or an unspecified 158 mechanism. However, third party ISPs are not considered an 159 important scenario for the IPv6 deployment, and are considered out 160 of scope. 162 o More complex forms of NAT traversal: the case where the tunnel 163 endpoint is visible (from the ISP point of view) behind a public 164 IPv4 address, and no other tunnel endpoints are using that address 165 is in scope. However, the case where multiple nodes would want to 166 initiate a tunnel from behind a "big" NAT, which maps them all to 167 a single address, is defined out of scope. The customer which has 168 multiple nodes can still use IPv6 behind such a NAT by selecting 169 one of the nodes to provide IPv6 access through the tunnel, and 170 have IPv6 connectivity routed or proxied as normal by the tunnel 171 endpoint node. The case where the ISP has deployed a single "big" 172 NAT affecting many customers can be addressed by the ISP deploying 173 the tunnel router inside the privately addressed infrastructure 174 (remember that third party ISPs were out-of-scope as well), so 175 that no NAT traversal is needed in the first place, as the 176 connectivity to the ISP's tunnel router is native IPv6 or a 177 configured tunnel with a static public IPv4 address. 179 o Short-cut paths between the users (e.g, like 6to4 [7] or ISATAP 180 [8]): all the IPv6-over-IPv4 traffic flows through the tunnel 181 router; short-cut mechanisms are believed to be non-essential in 182 this environment of "short" tunnels, and add to complexity and 183 security risks. If the load on the tunnel router rises too high, 184 one could switch to offering native service instead, or deploying 185 additional tunnel routers. 187 3. Overview of the Procedure 189 Throughout this memo, two major operational modes, "managed" and 190 "ad-hoc" are described. It's expected that some ISPs would like to 191 use one, and some the other, and both approaches are described. 193 The procedure can be summarized as follows: 195 1. If the ISP requires prior agreement ("managed mode"), the 196 customer contacts the ISP off-band and registers as an IPv6 user. 198 2. The customer discovers (using one of a number of mechanisms) the 199 IPv4 tunnel end-point address of the ISP, and creates a 200 configured tunnel (encapsulating in either IP (protocol 41) 201 tunnel [1] or UDP (Section 6)) to the address, and sends a normal 202 Neighbor Discovery [2] (ND) Route Solicitation (RS) or a DHCPv6 203 [4] SOLICIT or prefix delegation request [5] message over the 204 tunnel. 206 3. The ISP's tunnel router sets up a configured tunnel towards the 207 customer's IPv4 address; the address may be obtained using a 208 number of mechanisms, or created ad-hoc ("ad-hoc mode") when 209 tunnel packets arrive. In the managed more, the tunnel interface 210 is typically pre-configured prior to receiving any packets from 211 the customer. 213 4. The ISP's tunnel router sends a normal ND Route Advertisement 214 (RA) or a further DHCPv6 message over the tunnel to the customer; 215 the prefix advertised is obtained using one of a number of 216 mechanisms. The customer automatically configures the prefix and 217 the addresses and uses them normally. 219 Note that the description includes DHCPv6, prefix delegation etc. 221 just for completeness. It is assumed than in most cases a simple ND 222 RS/RA exchange will suffice. However, as the procedure is agnostic 223 of the prefix assignment methods used, any other mechanism can be 224 used as well. 226 No new protocols are needed. Both in the managed and ad-hoc modes, 227 the customer can learn the tunnel address off-band. 229 In the managed mode, the ISP has to know the IPv4 address assigned to 230 the customer, configure a new IPv6 tunnel interface for the customer, 231 and reserve the IPv6 prefix that will be assigned; these have to be 232 configured on the tunnel router using operator-specific management 233 techniques (e.g, RADIUS). 235 In the ad-hoc mode, on the other hand, the tunnel router has to 236 implement a simple mechanism to allocate a new configured tunnel, 237 after successful validation (or authentication) procedures as 238 discussed in Section 5.5, for tunnel packets received from different 239 customers, and algorithmically derive an IPv6 prefix to be assigned 240 to the customer. 242 4. Customer-side Procedures 244 4.1 Possible Prior Agreement with the ISP 246 The ISP may require prior agreement or notification before a customer 247 is allowed to use their tunnel service. In that case, the customer 248 must contact the ISP using off-band mechanisms. Even if not 249 required, special requirements (e.g., a static IPv6 prefix when IPv4 250 address is dynamic, or a need for an IPv6 /48 prefix) may be easier 251 to fulfill if the user has contacted the ISP beforehand and the ISP 252 has made arrangements; only a /64 prefix (which will be dynamic if 253 the IPv4 address is dynamic) will be available in ad-hoc mode. 255 4.2 Learning and Configuring the Tunnel Endpoint 257 To get started, the customer has to learn the IPv4 address of the 258 ISP's tunnel router somehow. Possibilities include, for example: 260 o Using off-band mechanisms, e.g., from the ISP's web page. 262 o Using DNS to look up a service name by appending it to the DNS 263 search path provided by DHCPv4 (e.g. 264 "tunnel-service.example.com"). 266 o Using a (yet unspecified) DHCPv4 option. 268 o Using a pre-configured or pre-determined IPv4 anycast address, 269 whether in the private or public space; however, note the 270 considerations about embedding addresses in the nodes [14]. 272 o Using other, unspecified methods. 274 This memo does not (at least yet) take a stance on the selection of 275 the mechanism even though some are more problematic than others, but 276 it is assumed that the first or the second option should be enough 277 for everyone considering that the customer's own ISP is providing 278 IPv6 service. 280 Once the IPv4 address has been learned, it is configured as the 281 tunnel end-point for the configured IPv6-over-IPv4 tunnel. Unless 282 the user has a private IPv4 address, implying being behind a NAT, IP 283 encapsulation must be used; otherwise, the encapsulation can be 284 selected as described in Section 6. Note that this configuration can 285 even be done transparently to the user, with very little or no 286 configuration. 288 4.3 Tunnel Activation 290 Next, IPv6 is activated over the tunnel as normal; this could be done 291 either by a Neighbor Discovery RS, DHCPv6 Solicitation message, 292 DHCPv6 Prefix Delegation request message, or by simple manual 293 configuration (note: manual configuration does not work in the 294 "ad-hoc" operation, because there is no trigger to bring up the ISP's 295 interface). 297 The tunnel router responds to this query as normal by sending a Route 298 Advertisement or continuing with DHCP message exchanges. 300 4.4 Providing Connectivity to Other Nodes 302 If the customer has multiple nodes, they can each obtain their own 303 tunnel in the same manner as long as the nodes are not behind a NAT. 304 However, this is unoptimal especially if such nodes have internal 305 communications. 307 Instead, the customer may want to set up one node to as a Neighbor 308 Discovery proxy [15] for the /64 route advertisement received, or if 309 a less specific prefix (e.g., a /48) is being used, as a router for 310 the internal network(s). This does not need to be any more 311 complicated than just setting up the tunnel on one node. 313 5. ISP-side Procedures 314 5.1 Possible Prior Agreements with the Customers 316 The ISP may operate in either or both "managed" and "ad-hoc" modes. 317 In only the managed mode, a prior agreement with the customer is 318 needed to allow the customer to use IPv6 using this procedure. In 319 only the ad-hoc mode, no agreements with the customers are needed. In 320 both modes, "basic service" (a /64 prefix which will be dynamic if 321 the customer's IPv4 address is dynamic) can be offered, but more 322 advanced services (e.g., prefix delegation or a static prefix) are 323 offered to those with a prior agreement. 325 ISPs which operate in the managed mode must configure (e.g., manually 326 or using a script or configuration tool) the configured tunnels on 327 the tunnel router; also, they may want to create a link between the 328 stable customer identification and their IPv6 properties (e.g., a 329 prefix) especially if the IPv4 address is dynamic, to maintain the 330 stability of IPv6 properties even when the IPv4 address may change. 332 5.2 Learning the Customers' Tunnel Endpoint Addresses 334 The ISP must somehow obtain the tunnel endpoint address to be 335 configured for a configured tunnel. Every active customer has its 336 own configured tunnel interface on the tunnel router. 338 When operating in the managed mode, this could be done from e.g. 339 DHCPv4 leases, RADIUS or Diameter databases, other databases or some 340 other means. This information will be used to update the tunnel 341 end-point address on the configured tunnel interface when changing or 342 as appropriate; the updates can be done e.g. using management tools, 343 scripting, etc. -- because a change of IPv4 address must be reflected 344 without delay to the tunnel end-point address, this configuration 345 update should be immediately triggered by changes in the used 346 database or lease. 348 When operating in the ad-hoc mode, the tunnel server should create a 349 new configured tunnel interface for each IPv6-over-IPv4 tunnel with a 350 different IPv4 source address. The ISP should be aware of a 351 potential for a resource exhaustion if the number of customers rises 352 too high, but actual DoS attacks are not possible if the ISP has 353 secured its network as described in Section 5.5. Automatic creation 354 of configured tunnel interfaces requires only rather trivial 355 implementation [XXX: does this need elaboration?]. Performing 356 "garbage collection" on such tunnels, e.g. in a Least-Recently-Used 357 (LRU) manner may be called for if the number of tunnels rises too 358 high. However, this should only be done after sufficiently long 359 period has passed, as not to disturb the existing (but maybe dormant) 360 IPv6 connections over the tunnels. 362 If the ISP wants to support NAT traversal when protocol 41 forwarding 363 [16] is not implemented in all the NAT boxes used by the customers, 364 the ISP must also provide the support for UDP decapsulation at UDP 365 port TBD. The users should default to use protocol 41, but if the 366 initiating packet is encapsulated in UDP, the configured tunnel type 367 may be changed if supported. NAT traversal is further discussed in 368 Section 6. 370 5.3 Prefix Advertisement or Delegation 372 Each customer should be provided with at least a /64 prefix; this is 373 both practical (because /64 is required by Stateless Address 374 Autoconfiguration [3]), and architecturally correct (providing the 375 possibility to connect more than one node without an IPv6 NAT). 377 In the managed mode, the ISP may advertise a static or dynamic IPv6 378 /64 prefix using RAs, provide a prefix delegation, or something else 379 (e.g., manual configuration if the IPv4 address is static). 381 In the ad-hoc mode, the ISP must ensure that a sufficiently large 382 pool of /64 prefixes are available. The prefixes can be allocated 383 either in a sequential fashion and advertised in RA's, or 384 automatically calculated, with some assumptions, from the used IPv4 385 addresses. For example, if the ISP uses IPv4 network 10.0.0.0/8 for 386 its customers, it needs 24 bits to uniquely identify each customer -- 387 this calls for assigning an IPv6 /40 prefix to be used for 388 advertising /64's; in this example, a customer with address 389 "10.1.2.3" might get advertised an IPv6 prefix "2001:db8:FF01:0203::/ 390 64", where "01:0203" corresponds to the client address and 391 "2001:db8:FF00::" the /40 allocated to the ad-hoc tunneling 392 operations by the ISP. Mapping the most interesting bits (for the 393 ISP) of an IPv4 address to the IPv6 prefix allows even large ISPs to 394 easily give each user an algorithmically derived IPv6 prefix. 396 5.4 Tunnel Activation and Maintenance 398 When the router receives e.g. ND RS, DHCPv6 SOLICIT or prefix 399 delegation request from the configured tunnel, it responds normally, 400 as on any other interface. (When in ad-hoc mode, setting up the 401 tunnel from the received IPv6-over-IPv4 packet may take a while, but 402 the processing continues when set up.) 404 The ISP should avoid sending periodic messages (e.g., unsolicited 405 route advertisements) to the tunnel, or decrease the interval used 406 for sending them: if the customer disconnects for some time, and 407 someone else gets the same address, it might be disturbing to the 408 new, potentially non-IPv6 aware customer to receive "weird" protocol 409 41 or UDP packets meant to the previous customer. The similar effect 410 occurs if someone in the Internet is trying to communicate with an 411 IPv6 user, but the user has changed its address in the meantime, and 412 packets may go to someone else's IPv4 address. However, this is no 413 different to the situation with IPv4 today, except that the packets 414 may be discarded by the operating system and never even be noticed; 415 but if they are noticed, e.g., by a personal firewall, they may not 416 be recognized and may cause more alarm. 418 5.5 Secure Operations for Tunnel Service 420 The ISP should perform IPv4 ingress filtering at its borders towards 421 peers and upstreams, by disallowing packets with the source addresses 422 belonging to its own site or its customers. In particular, the ISP 423 must block the tunnel router's address from being used as a source 424 address from the outside; blocking the use of the customer prefixes 425 would be preferred as well. 427 The ISP must perform IPv4 ingress filtering towards the customers, in 428 particular those that use the tunnel service, so that they will not 429 be able to forge the IPv4 source address of the packets. In 430 particular, they must not be able to spoof the address of the tunnel 431 router to the other customers. 433 Both of these are very simple operations especially in the minimal 434 case of blocking only the abuse of the tunnel router address. 436 Naturally, the ISP should perform IPv6 ingress filtering as well, but 437 that is orthogonal to the security of this procedure. 439 In addition, the ISP must ensure, especially if in ad-hoc mode, that 440 only a selected subset of source addresses is able to communicate 441 with the tunnel router's designated tunnel address. For example, 442 creating dynamic interfaces with packets from outside of the ISP's 443 network could easily be used in a resource exhaustion attack. In 444 addition, to curtail internal resource exhaustion attacks, it makes 445 very much sense to ingress filter all the customers which are allowed 446 to use the ad-hoc tunnel service. With these precautions, resources 447 may only be exhausted by a real resource starvation, not through an 448 attack; on the other hand, if the ISP does not bother to add such 449 checks, it only harms itself for being susceptible to various forms 450 of attacks! 452 5.6 Sufficient Tunnel Service Provisioning 454 The ISP must naturally ensure that the tunnel router is capable to 455 handle the amount of users and the traffic that goes through it. It 456 should also be noted that all the traffic between the users of the 457 ISP go through the same router; "shortcuts" routes are not deemed 458 necessary. The increases in the latency are not significant as the 459 tunnel router is deployed close to the IPv4 access router (or even 460 co-located with it) topology-wise. 462 Typically, these are not believed to be problems. If the number of 463 users or the amount of traffic generated increases, starting 464 deploying native IPv6 access instead eliminates the problem, or the 465 ISP could deploy more tunnel routers in a load-balancing 466 configuration -- depending on the mechanism used to find the tunnel 467 service, this could be e.g., through DNS load-balancing, anycasting 468 the tunnel service address, etc. 470 6. NAT Traversal 472 NAT traversal may be desirable especially in the case when the 473 customer gets one IPv4 address from the ISP, which is assigned on the 474 IPv4 gateway, and NAT'ed access is provided to the customer's nodes. 475 If the gateway cannot be IPv6-enabled, the customer may want to 476 obtain the access from an internal node to bypass the gateway and the 477 NAT. 479 There are two ways to do this: (1) ensuring that the NAT forwards 480 protocol 41 packets [16], or (2) providing a minimal UDP 481 encapsulation to the tunnel packets. 483 Forwarding protocol 41 packets is simple if implemented by the NAT 484 gateway; this requires no administrative set-up. This works 485 (basically) for one node behind the NAT at the time -- however, 486 multiple nodes behind a single public IPv4 address was considered out 487 of scope. 489 If protocol 41 packets are not forwarded, a minimal UDP encapsulation 490 may be needed: instead of using protocol 41, UDP is used with the 491 minimal headers. This adds 8 bytes to the packets, and should be 492 taken into consideration with configured tunnel MTU calculations [1]. 493 The routers should use a UDP port TBD by default to de-multiplex UDP 494 configured tunnels. The tunnels are identified in SNMP by udp(8) 495 IANAtunnelType [20]. 497 The customer using private addresses behind a NAT must select which 498 method to use. It is recommended to try protocol 41 first; if no 499 response is received, UDP encapsulation may be tried instead. Note 500 that this choice of the encapsulation may be completely transparent 501 to the user as well. 503 With UDP encapsulation, the algorithmically derived prefix assignment 504 is kept simple with the assumption that every tunnel service user can 505 be identified with a public IPv4 address; whether the tunnel 506 originates inside a NAT does not matter. That way, for 507 UDP-encapsulated configured tunnels, the tunnel router only 508 additionally needs to keep a record of the source UDP port each 509 customer uses. 511 However, NAT mappings must be maintained whether UDP or protocol 41 512 is being used. It is recommended to do this by the customer 513 activating ND Neighbor Unreachability Detection (NUD) on the 514 configured tunnel; the default value for DELAY_FIRST_PROBE_TIME is 5 515 seconds [2]; this is enough, and could even be increased to e.g., 60 516 seconds for this link type. Increasing it further may have adverse 517 effects as the NAT UDP/proto-41 mapping lifetimes typically vary from 518 60..200 seconds. No protocol is proposed to discover and use the 519 most optimal lifetimes for the particular NAT; this is not believed 520 to be worth the robustness losses. 522 7. Acknowledgements 524 This procedure was inspired by a need to severely simplify ISATAP 525 [8]. Suresh Satapati coined up the name, and provided useful 526 feedback. Gert Doering, Marc Blanchet and Janos Mohacsi participated 527 in the discussion clarifying the applicability. 529 8. IANA Considerations 531 This memo requests an allocation of a "privileged" UDP port (TBD). 533 9. Security Considerations 535 The requirements for reasonably secure operations within an ISP are 536 described in Section 5.5; with these in place, it is difficult to 537 imagine a case where stronger mechanisms such as IPsec for 538 IPv6-over-IPv4 tunnels would be needed. 540 A particular case occurs when an IPv4 address of the user changes, 541 and the user's IPv6 prefix changes as well; this may be allocated to 542 a different IPv6 user. However, this is no different than IPv4 543 address re-use threats. [XXX: can be considered more if really 544 needed.] 546 When the ISP operates in the ad-hoc mode, and there is an event where 547 all the IPv4 addresses change simultaneously, there may be a large 548 number of simultaneous updates to update the tunnel point addresses 549 in the tunnel router. This situation should be taken into 550 consideration e.g. if renumbering. 552 The case where a third party ISP provides the service was decreed out 553 of scope, because it is impractical and economically unfeasible, and 554 has a number of security problems as well. Similarly, multiple users 555 behind a single NAT'ted public IPv4 address seems to be only relevant 556 in the third party case and is equally out of scope; this would have 557 security implications as well, as it would be relatively easy to 558 hijack someone else's IPv6 prefix. 560 Normative References 562 [1] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 563 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-01 (work in 564 progress), October 2003. 566 [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 567 IP Version 6 (IPv6)", RFC 2461, December 1998. 569 [3] Thomson, S. and T. Narten, "IPv6 Stateless Address 570 Autoconfiguration", RFC 2462, December 1998. 572 [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 573 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 574 RFC 3315, July 2003. 576 [5] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 577 Configuration Protocol (DHCP) version 6", RFC 3633, December 578 2003. 580 Informative References 582 [6] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. 583 Lear, "Address Allocation for Private Internets", BCP 5, RFC 584 1918, February 1996. 586 [7] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 587 IPv4 Clouds", RFC 3056, February 2001. 589 [8] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site 590 Automatic Tunnel Addressing Protocol (ISATAP)", 591 draft-ietf-ngtrans-isatap-17 (work in progress), January 2004. 593 [9] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and 594 B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, 595 August 1999. 597 [10] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 598 December 1998. 600 [11] Blanchet, M., "Tunnel Setup Protocol (TSP)A Control Protocol to 601 Setup IPv6 or IPv4 Tunnels", draft-vg-ngtrans-tsp-01 (work in 602 progress), July 2002. 604 [12] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", 605 draft-huitema-v6ops-teredo-00 (work in progress), June 2003. 607 [13] Massar, J., "SixXS Heartbeat Protocol", 608 draft-massar-v6ops-heartbeat-00 (work in progress), January 609 2004. 611 [14] Plonka, D., "Embedding Globally Routable Internet Addresses 612 Considered Harmful", draft-ietf-grow-embed-addr-00 (work in 613 progress), December 2003. 615 [15] Thaler, D. and M. Talwar, "Bridge-like Neighbor Discovery 616 Proxies (ND Proxy)", draft-thaler-ipv6-ndproxy-01 (work in 617 progress), October 2003. 619 [16] Palet, J., "Forwarding Protocol 41 in NAT Boxes", 620 draft-palet-v6ops-proto41-nat-03 (work in progress), October 621 2003. 623 [17] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", 624 draft-ietf-v6ops-3gpp-analysis-07 (work in progress), October 625 2003. 627 [18] Huitema, C., "Evaluation of Transition Mechanisms for Unmanaged 628 Networks", draft-ietf-v6ops-unmaneval-00 (work in progress), 629 June 2003. 631 [19] Lind, M., "Scenarios and Analysis for Introducing IPv6 into ISP 632 Networks", draft-ietf-v6ops-isp-scenarios-analysis-00 (work in 633 progress), December 2003. 635 [20] Thaler, D., "IP Tunnel MIB", draft-thaler-inet-tunnel-mib-00 636 (work in progress), October 2003. 638 Author's Address 640 Pekka Savola 641 CSC/FUNET 643 Espoo 644 Finland 646 EMail: psavola@funet.fi 648 Appendix A. Comparison to Other Mechanisms and Procedures 650 This mechanism can be compared to several other proposed mechanisms 651 and proposals: pure configured tunnels, the use of Layer 2 Tunneling 652 Protocol (L2TP [9]), use of 6to4 [7], an instance of Tunnel Broker 653 concept -- TSP [11], ISATAP [8], and Teredo [12]. 655 Since obtaining IPv6 connectivity without the support of your own ISP 656 is out-of-scope, we exclude 6to4 and Teredo from the comparison. 657 Now's let's take a look at the rest. 659 A.1 Configured Tunnels 661 Configured tunnels are preferable in every case where they can be 662 used. However, it's difficult to manage them especially in the cases 663 where dynamic (but public) IPv4 addresses are being used, when the 664 user needs IPv6 connectivity to nodes behind the user's own NAT 665 gateway (which doesn't implement protocol-41 forwarding), or when the 666 amount of configuration must be kept to the minimum. 668 A.2 L2TP 670 L2TP could be leveraged by using UDP (passes NATs) to encapsulate PPP 671 frames toward the customers. The customers would have to have an 672 L2TP client and IPv6-capable PPP, and the ISP would have to have an 673 L2TP server, a management system for the IPv6 attributes (e.g., 674 RADIUS), and a configured address pool. Additionally, as IPV6CP PPP 675 negotiation does not allow prefix delegation, DNS resolver 676 configuration, etc., one might have to run (especially if more than 677 one address is required) an additional protocol, e.g. DHCPv6 for 678 prefix delegation, on the link. 680 The ISPs which already have L2TP, PPP and RADIUS infrastructures 681 (e.g., for dial-up IPv6 users, or certain classes of xDSL users), the 682 additional set-up complexity would not be high; for those which do 683 not, this would be a rather complicated set of operations. Naturally, 684 the customer operating systems would have to support L2TP and PPP as 685 well. 687 L2TP clearly has its strenghts, but some ISPs might see it as too 688 complicated to set up. Also, if the ISP wishes to offer an "ad-hoc" 689 operations (as seems to be the case in 3GPP at least), the amount of 690 infrastructure required might be too high. 692 A.3 Tunnel Broker Solutions 694 A large number of custom tunnel brokering solutions have been used. 695 For example, many (open-source) VPN products offer the capabilities 696 of providing IPv6 service through the VPN. Multiple tunnel brokers 697 have also been deployed, e.g. by SixXS [13], Viagenie, and others. 698 We'll look at Tunnel Setup Protocol (TSP) as an instance of this 699 model. 701 TSP provides a similar set of functions as STEP. However, TSP has an 702 overhead of a signalling protocol, which is not needed in STEP. TSP 703 offers a custom way of prefix delegation, while STEP relies on 704 standard mechanisms like DHCPv6 Prefix Delegation, or the use of ND 705 proxying. TSP works also for tunnel configuration across ISPs, which 706 was out of scope for STEP. STEP is transparent to the user, but TSP 707 requires a client software and some form of set-up. 709 A.4 ISATAP 711 ISATAP provides many features, like automatic tunneling between 712 ISATAP nodes in the same ISATAP site, which was decreed insecure and 713 out of scope for STEP. The insecurity rises from the applying ISATAP 714 in scenarios where the bounds of an ISATAP site are larger than the 715 bounds of an administrative domain, leading to e.g., issues with the 716 trust of the pseudo-interface when a packet with Hop Limit=255 and a 717 link-local address is received. STEP has no such assumptions, and 718 it's security properties are about the same as using bidirectional 719 configured tunnels. 721 Appendix B. Multiple Users Behind a NATted IPv4 Address 723 The scenario where multiple users are behind a single NAT'ed IPv4 724 address (e.g., when using a third party ISP) was decreed out of 725 scope. However, the possibility to achieve that is shown, even though 726 it is not considered to be useful. 728 Providing service to multiple users would require nothing more than a 729 change in the algorithm used to derive the customer's prefix. Of 730 course, at first glance this appears to be problematic, as mapping 16 731 additional bits to the IPv6 address may seem like a challenge. 732 However, this is not the case; such support is only needed for 733 (out-of-scope) third party ISP case, which must operate in the 734 managed mode, and the prefix assignment cannot be done based on the 735 address anyway, so there is no real problem with this approach. 737 Intellectual Property Statement 739 The IETF takes no position regarding the validity or scope of any 740 intellectual property or other rights that might be claimed to 741 pertain to the implementation or use of the technology described in 742 this document or the extent to which any license under such rights 743 might or might not be available; neither does it represent that it 744 has made any effort to identify any such rights. Information on the 745 IETF's procedures with respect to rights in standards-track and 746 standards-related documentation can be found in BCP-11. Copies of 747 claims of rights made available for publication and any assurances of 748 licenses to be made available, or the result of an attempt made to 749 obtain a general license or permission for the use of such 750 proprietary rights by implementors or users of this specification can 751 be obtained from the IETF Secretariat. 753 The IETF invites any interested party to bring to its attention any 754 copyrights, patents or patent applications, or other proprietary 755 rights which may cover technology that may be required to practice 756 this standard. Please address the information to the IETF Executive 757 Director. 759 Full Copyright Statement 761 Copyright (C) The Internet Society (2004). All Rights Reserved. 763 This document and translations of it may be copied and furnished to 764 others, and derivative works that comment on or otherwise explain it 765 or assist in its implementation may be prepared, copied, published 766 and distributed, in whole or in part, without restriction of any 767 kind, provided that the above copyright notice and this paragraph are 768 included on all such copies and derivative works. However, this 769 document itself may not be modified in any way, such as by removing 770 the copyright notice or references to the Internet Society or other 771 Internet organizations, except as needed for the purpose of 772 developing Internet standards in which case the procedures for 773 copyrights defined in the Internet Standards process must be 774 followed, or as required to translate it into languages other than 775 English. 777 The limited permissions granted above are perpetual and will not be 778 revoked by the Internet Society or its successors or assignees. 780 This document and the information contained herein is provided on an 781 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 782 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 783 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 784 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 785 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 787 Acknowledgment 789 Funding for the RFC Editor function is currently provided by the 790 Internet Society.