idnits 2.17.1 draft-ietf-ngtrans-broker-05.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1933 (ref. '1') (Obsoleted by RFC 2893) ** Downref: Normative reference to an Informational RFC: RFC 2504 (ref. '7') ** Obsolete normative reference: RFC 2571 (ref. '8') (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 2574 (ref. '9') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2575 (ref. '10') (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2137 (ref. '11') (Obsoleted by RFC 3007) ** Obsolete normative reference: RFC 2401 (ref. '12') (Obsoleted by RFC 4301) Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Alain Durand 2 INTERNET-DRAFT SUN Microsystems, Inc 3 September 21, 2000 Paolo Fasano 4 Expires March 20, 2001 Ivano Guardini 5 CSELT S.p.A. 6 Domenico Lento 7 TIM 9 IPv6 Tunnel Broker 10 12 Status of Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The IPv6 global Internet as of today is mostly built using tunnels over 36 the existing IPv4 infrastructure. Those tunnels are difficult to 37 configure and maintain in a large scale environment. The 6bone has 38 proven that large sites and ISPs can do it, but this process is too 39 complex for the isolated end user who already has an IPv4 connection and 40 would like to enter the IPv6 world. The motivation for the development 41 of the tunnel broker model is to help early IPv6 adopters to hook up 42 to an existing IPv6 network (e.g. the 6bone) and to get stable, 43 permanent IPv6 addresses and DNS names. The concept of the tunnel broker 44 was first presented at Orlando's IETF in December 1998. Two 45 implementations were demonstrated during the Grenoble IPng & NGtrans 46 interim meeting. 48 Internet Draft draft-ietf-ngtrans-broker-05.txt 50 1. Introduction 52 The growth of IPv6 networks started mainly using the transport 53 facilities offered by the current Internet. This led to the 54 development of several techniques to manage IPv6 over IPv4 tunnels. At 55 present most of the 6bone network is built using manually configured 56 tunnels over the Internet. The main drawback of this approach is the 57 overwhelming management load for network administrators, who have to 58 perform extensive manual configuration for each tunnel. Several 59 attempts to reduce this management overhead have already been proposed 60 and each of them presents interesting advantages but also solves 61 different problems than the Tunnel Broker, or poses drawbacks not 62 present in the Tunnel Broker: 64 - the use of automatic tunnels with IPv4 compatible addresses [1] 65 is a simple mechanism to establish early IPv6 connectivity among 66 isolated dual-stack hosts and/or routers. The problem with this 67 approach is that it does not solve the address exhaustion problem 68 of IPv4. Also there is a great fear to include the complete IPv4 69 routing table into the IPv6 world because this would worsen the 70 routing table size problem multiplying it by 5; 71 - 6over4 [2] is a site local transition mechanism based on the 72 use of IPv4 multicast as a virtual link layer. It does not solve 73 the problem of connecting an isolated user to the global IPv6 74 Internet; 75 - 6to4 [3] has been designed to allow isolated IPv6 domains, attached 76 to a wide area network with no native IPv6 support (e.g. the IPv4 77 Internet), to communicate with other such IPv6 domains with minimal 78 manual configuration. The idea is to embed IPv4 tunnel addresses 79 into the IPv6 prefixes so that any domain border router can 80 automatically discover tunnel endpoints for outbound IPv6 traffic. 82 The Tunnel Broker idea is an alternative approach based on the provision 83 of dedicated servers, called Tunnel Brokers, to automatically manage 84 tunnel requests coming from the users. This approach is expected 85 to be useful to stimulate the growth of IPv6 interconnected hosts and to 86 allow early IPv6 network providers to provide easy access to their IPv6 87 networks. 89 The main difference between the Tunnel Broker and the 6to4 mechanisms 90 is that the they serve a different segment of the IPv6 community: 91 - the Tunnel Broker fits well for small isolated IPv6 sites, and 92 especially isolated IPv6 hosts using dial-up IPv4 connections, that 93 want to easily connect to an existing IPv6 network; 94 - the 6to4 approach has been designed to allow isolated IPv6 sites to 95 easily connect together without having to wait for their IPv4 ISPs to 96 deliver native IPv6 services. This is very well suited for extranet 97 and virtual private networks. Using 6to4 relays, 6to4 sites can also 98 reach sites on the IPv6 Internet. 100 In addition, the Tunnel Broker approach allows IPv6 ISPs to easily 101 perform access control on the users enforcing their own policies on 102 network resources utilization. 104 Internet Draft draft-ietf-ngtrans-broker-05.txt 106 This document is intended to present a framework describing the 107 guidelines for the provision of a Tunnel Broker service within the 108 Internet. It does not specify any protocol but details the general 109 architecture of the proposed approach. It also outlines a set of viable 110 alternatives for implementing it. 111 Section 2 provides an overall description of the Tunnel Broker model; 112 Section 3 reports known limitations to the model; 113 Section 4 briefly outlines other possible applications of the Tunnel 114 Broker approach; 115 Section 5 addresses security issues. 117 2. Tunnel Broker Model 119 Tunnel brokers can be seen as virtual IPv6 ISPs, providing IPv6 120 connectivity to users already connected to the IPv4 Internet. In the 121 emerging IPv6 Internet it is expected that many tunnel brokers will be 122 available so that the user will just have to pick one. The list of the 123 tunnel brokers should be referenced on a "well known" web page (e.g. 124 on http://www.ipv6.org) to allow users to choose the "closest" one, 125 the "cheapest" one, or any other one. 127 The tunnel broker model is based on the set of functional elements 128 depicted in figure 1. 130 +------+ 131 /|tunnel| 132 / |server| 133 / | | 134 / +------+ 135 +----------+ +------+/ +------+ 136 |dual-stack| |tunnel| |tunnel| 137 | node |<--->|broker|<--->|server| 138 | (user) | | | | | 139 +----------+ +------+\ +------+ 140 | \ +------+ 141 tunnel end-point v \ |tunnel| 142 /\ +---+ \ |server| 143 || |DNS| \| | 144 || +---+ +------+ 145 || 146 || tunnel end-point 147 || /\ 148 || || 149 |+---------------------------+| 150 +-----------------------------+ 151 IPv6 over IPv4 tunnel 153 Figure 1: the Tunnel Broker model 155 Internet Draft draft-ietf-ngtrans-broker-05.txt 157 2.1 Tunnel Broker (TB) 159 The TB is the place where the user connects to register and activate 160 tunnels. The TB manages tunnel creation, modification and deletion on 161 behalf of the user. 163 For scalability reasons the tunnel broker can share the load of 164 network side tunnel end-points among several tunnel servers. 165 It sends configuration orders to the relevant tunnel server whenever a 166 tunnel has to be created, modified or deleted. The TB may also register 167 the user IPv6 address and name in the DNS. 169 A TB must be IPv4 addressable. It may also be IPv6 addressable, 170 but this is not mandatory. Communications between the broker 171 and the servers can take place either with IPv4 or IPv6. 173 2.2 Tunnel server (TS) 175 A TS is a dual-stack (IPv4 & IPv6) router connected to the global 176 Internet. Upon receipt of a configuration order coming from the TB, it 177 creates, modifies or deletes the server side of each tunnel. It may 178 also maintain usage statistics for every active tunnel. 180 2.3 Using the Tunnel Broker 182 The client of the Tunnel Broker service is a dual-stack IPv6 node 183 (host or router) connected to the IPv4 Internet. Approaching the TB, 184 the client should be asked first of all to provide its identity and 185 credentials so that proper user authentication, authorization and 186 (optionally) accounting can be carried out (e.g. relying on existing 187 AAA facilities such as RADIUS). This means that the client and the 188 TB have to share a pre-configured or automatically established 189 security association to be used to prevent unauthorized use of the 190 service. With this respect the TB can be seen as an access-control 191 server for IPv4 interconnected IPv6 users. 193 Once the client has been authorized to access the service, it should 194 provide at least the following information: 196 - the IPv4 address of the client side of the tunnel; 197 - a name to be used for the registration in the DNS of the global 198 IPv6 address assigned to the client side of the tunnel; 199 - the client function (i.e. standalone host or router). 201 Moreover, if the client machine is an IPv6 router willing to provide 202 connectivity to several IPv6 hosts, the client should be asked also 203 to provide some information about the amount of IPv6 addresses required. 204 This allows the TB to allocate the client an IPv6 prefix that fits its 205 needs instead of a single IPv6 address. 207 Internet Draft draft-ietf-ngtrans-broker-05.txt 209 The TB manages the client requests as follows: 210 - it first designates (e.g. according to some load sharing criteria 211 defined by the TB administrator) a Tunnel Server to be used 212 as the actual tunnel end-point at the network side; 213 - it chooses the IPv6 prefix to be allocated to the client; the 214 prefix length can be anything between 0 and 128, most common values 215 beeing 48 (site prefix), 64 (subnet prefix) or 128 (host prefix); 216 - it fixes a lifetime for the tunnel; 217 - it automatically registers in the DNS the global IPv6 addresses 218 assigned to the tunnel end-points; 219 - it configures the server side of the tunnel; 220 - it notifies the relevant configuration information to the client, 221 including tunnel parameters and DNS names. 223 After the above configuration steps have been carried out (including 224 the configuration of the client), the IPv6 over IPv4 tunnel between 225 the client host/router and the selected TS is up and working, thus 226 allowing the tunnel broker user to get access to the 6bone or any 227 other IPv6 network the TS is connected to. 229 2.4 IPv6 address assignment 231 The IPv6 addresses assigned to both sides of each tunnel must be 232 global IPv6 addresses belonging to the IPv6 addressing space 233 managed by the TB. 235 The lifetime of these IPv6 addresses should be relatively long and 236 potentially longer than the lifetime of the IPv4 connection of the 237 user. This is to allow the client to get semipermanent IPv6 addresses 238 and associated DNS names even though it is connected to the Internet 239 via a dial-up link and gets dynamically assigned IPv4 addresses 240 through DHCP. 242 2.5 Tunnel management 244 Active tunnels consume precious resources on the tunnel servers in 245 terms of memory and processing time. For this reason it is advisable 246 to keep the number of unused tunnels as small as possible deploying a 247 well designed tunnel management mechanism. 249 Each IPv6 over IPv4 tunnel created by the TB should at least be 250 assigned a lifetime and removed after its expiration unless an 251 explicit lifetime extension request is submitted by the client. 253 Obviously this is not an optimal solution especially for users 254 accessing the Internet through short-lived and dynamically addressed 255 IPv4 connections (e.g. dial-up links). In this case a newly 256 established tunnel is likely to be used just for a short time and 257 then never again, in that every time the user reconnects he gets a 258 new IPv4 address and is therefore obliged either to set-up a new 259 tunnel or to update the configuration of the previous one. In 260 such a situation a more effective tunnel management may be achieved 261 by having the TS periodically deliver to the TB IPv6 traffic and 262 Internet Draft draft-ietf-ngtrans-broker-05.txt 264 reachability statistics for every active tunnel. In this way, 265 the TB can enforce a tunnel deletion after a period of inactivity 266 without waiting for the expiration of the related lifetime which can 267 be relatively longer (e.g. several days). 269 Another solution may be to implement some kind of tunnel management 270 protocol or keep-alive mechanism between the client and the TS (or 271 between the client and the TB) so that each tunnel can be immediately 272 released after the user disconnects (e.g. removing his tunnel end-point 273 or tearing down his IPv4 connection to the Internet). The drawback of 274 this policy mechanism is that it also requires a software upgrade on 275 the client machine in order to add support for the ad-hoc keep-alive 276 mechanism described above. 278 Moreover, keeping track of the tunnel configuration even after the user 279 has disconnected from the IPv4 Internet may be worth the extra cost. In 280 this way, in fact, when the user reconnects to the Internet, possibly 281 using a different IPv4 address, he could just restart the tunnel by 282 getting in touch with the TB again. The TB could then order a TS to 283 re-create the tunnel using the new IPv4 address of the client but 284 reusing the previously allocated IPv6 addresses. That way, the client 285 could preserve a nearly permanent (static) IPv6 address even though 286 its IPv4 address is dynamic. It could also preserve the associated 287 DNS name. 289 2.6 Interactions between client, TB, TS and DNS 291 As previously stated, the definition of a specific set of protocols 292 and procedures to be used for the communication among the various 293 entities in the Tunnel Broker architecture is outside of the scope of 294 the present framework document. Nevertheless, in the reminder of this 295 section some viable technical alternatives to support client-TB, 296 TB-TS and TB-DNS interactions are briefly described in order to help 297 future implementation efforts or standardization initiatives. 299 The interaction between the TB and the user could be based on http. 300 For example the user could provide the relevant configuration 301 information (i.e. the IPv4 address of the client side of the tunnel, 302 etc.) by just filling up some forms on a Web server running on the TB. 303 As a result the server could respond with an html page stating that 304 the server end-point of the tunnel is configured and displaying all 305 the relevant tunnel information. 307 After that, the most trivial approach would be to leave the user to 308 configure the client end-point of the tunnel on his own. However, it 309 should be highly valuable to support a mechanism to automate this 310 procedure as much as possible. 312 Several options may be envisaged to assist the Tunnel Broker user in 313 the configuration of his dual-stack equipment. The simplest option 314 is that the TB could just prepare personalized activation and de- 315 activation scripts to be run off-line on the client machine to 316 achieve easy set-up of the client side tunnel end-point. This solution 317 Internet Draft draft-ietf-ngtrans-broker-05.txt 319 is clearly the easiest to implement and operate in that it does not 320 require any software extension on the client machine. However, it 321 raises several security concerns because it may be difficult for the 322 user to verify that previously downloaded scripts do not perform 323 illegal or dangerous operations once executed. 325 The above described security issues could be elegantly overcome by 326 defining a new MIME (Multipurpose Internet Mail Extension) content-type 327 (e.g. application/tunnel) [4,5] to be used by the TB to deliver the 328 tunnel parameters to the client. In this case, there must be a dedicated 329 agent running on the client to process this information and actually 330 set-up the tunnel end-point on behalf of the user. This is a very 331 attractive approach which is worth envisaging. In particular, the 332 definition of the new content-type might be the subject of a future 333 ad-hoc document. 335 Several options are available also to achieve proper interaction 336 between the broker and the Tunnel Servers. For example a set of simple 337 RSH commands over IPsec could be used for this purpose. Another 338 alternative could be to use SNMP or to adopt any other network 339 management solution. 341 Finally, the Dynamic DNS Update protocol [6] should be used for 342 automatic DNS update (i.e. to add or delete AAAA, A6 and PTR records 343 from the DNS zone reserved for Tunnel Broker users) controlled by the 344 TB. A simple alternative would be for the TB to use a small set of RSH 345 commands to dynamically update the direct and inverse databases on the 346 authoritative DNS server for the Tunnel Broker users zone (e.g. 347 broker.isp-name.com). 349 2.7 Open issues 351 Real usage of the TB service may require the introduction of 352 accounting/billing functions. 354 3. Known limitations 356 This mechanism may not work if the user is using private IPv4 addresses 357 behind a NAT box. 359 4. Use of the tunnel broker concept in other areas 361 The Tunnel Broker approach might be efficiently exploited also to 362 automatically set-up and manage any other kind of tunnel, such as a 363 multicast tunnel (e.g. used to interconnect multicast islands within 364 the unicast Internet) or an IPsec tunnel. 366 Moreover, the idea of deploying a dedicated access-control server, 367 like the TB, to securely authorize and assist users that want to gain 368 access to an IPv6 network might prove useful also to enhance other 369 transition mechanisms. For example it would be possible to exploit 370 a similar approach within the 6to4 model to achieve easy relay 371 discovery. This would make life easier for early 6to4 adopters but 372 Internet Draft draft-ietf-ngtrans-broker-05.txt 374 would also allow the ISPs to better control the usage of their 6to4 375 relay facilities (e.g. setting up appropriate usage policies). 377 5. Security Considerations 379 All the interactions between the functional elements of the proposed 380 architecture need to be secured: 382 - the interaction between the client and TB; 383 - the interaction between the TB and the Tunnel Server; 384 - the interaction between the TB and the DNS. 386 The security techniques adopted for each of the required interactions 387 is dependent on the implementation choices. 389 For the client-TB interaction, the usage of http allows the exploitation 390 of widely adopted security features, such as SSL (Secure Socket Layer) 391 [7], to encrypt data sent to and downloaded from the web server. This 392 also makes it possible to rely on a simple "username" and "password" 393 authentication procedure and on existing AAA facilities (e.g. RADIUS) to 394 enforce access-control. 396 For the TB-TS interaction secure SNMP could be adopted [8,9,10]. If the 397 dynamic DNS update procedure is used for the TB-DNS interaction, the 398 security issues are the same as discussed in [11]. Otherwise, if a 399 simpler approach based on RSH commands is used, standard IPsec 400 mechanisms can be applied [12]. 402 Furthermore, if the configuration of the client is achieved running 403 scripts provided by the TB, these scripts must be executed with 404 administrator/root privileges. This can be dangerous and should 405 be considered only for early implementations of the Tunnel Broker 406 approach. Transferring tunnel configuration parameters in a MIME type 407 over https is a more secure approach. 409 In addition a loss of confidentiality may occur whenever a dial-up 410 user disconnects from the Internet without tearing down the tunnel 411 previously established through the TB. In fact, the TS keeps 412 tunneling the IPv6 traffic addressed to that user to his old IPv4 413 address regardless of the fact that in the meanwhile that IPv4 address 414 could have been dynamically assigned to another subscriber of the same 415 dial-up ISP. This problem could be solved by implementing on every 416 tunnel the keep-alive mechanism outlined in section 2.5 thus allowing 417 the TB to immediately stop IPv6 traffic forwarding towards 418 disconnected users. 420 Finally TBs must implement protections against denial of service 421 attacks which may occur whenever a malicious user exhausts all the 422 resources available on the tunnels server by asking for a lot of tunnels 423 to be established altogether. A possible protection against this 424 attack could be achieved by administratively limiting the number of 425 tunnels that a single user is allowed to set-up at the same time. 427 Internet Draft draft-ietf-ngtrans-broker-05.txt 429 6. Acknowledgments 431 Some of the ideas refining the tunnel broker model came from discussion 432 with Perry Metzger and Marc Blanchet. 434 7. References 436 [1] Gilligan, R., Nordmark, E., "Transition Mechanisms for IPv6 Hosts 437 and Routers", RFC 1933, April 1996. 438 [2] Carpenter, B., Jung, C., "Transmission of IPv6 over IPv4 Domains 439 without Explicit Tunnels", RFC 2529, March 1999. 440 [3] Carpenter, B., Moore, K., "Connection of IPv6 Domains via IPv4 441 Clouds without Explicit Tunnels", draft-ietf-ngtrans-6to4-07.txt, 442 work in progress, September 2000. 443 [4] Freed, N., Borenstein, N., "Multipurpose Internet Mail Extensions 444 (MIME) Part One: Format of Internet Message Bodies, RFC 2045, 445 November 1996. 446 [5] Freed, N., Borenstein, N., "Multipurpose Internet Mail Extensions 447 (MIME) Part Two: Media Types", RFC 2046, November 1996. 448 [6] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound, "Dynamic 449 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 450 1997. 451 [7] Guttman, E., Leong, L., Malkin, G., "Users' Security Handbook", 452 RFC 2504, February 1999. 453 [8] Wijnen, B., Harrington, D., Presuhn, R., "An Architecture for 454 Decribing SNMP Management Frameworks", RFC 2571, April 1999. 455 [9] Blumenthal, U., Wijnen, B., "User-based Security Model (USM) for 456 version 3 of the Simple Network Management Protocol (SNMPv3)", 457 RFC 2574, April 1999. 458 [10] Wijnen, B., Presuhn, R., McCloghrie, K., "View-based Access Control 459 Model (VACM) for the Simple Network Management Protocol (SNMP)", 460 RFC 2575, April 1999. 461 [11] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, 462 April 1997. 463 [12] Kent, S., Atkinson, R., "Security Architecture for the Internet 464 Protocol", RFC 2401, November 1998. 466 8. Author's addresses 468 Alain Durand 469 SUN Microsystems, Inc 470 901 San Antonio Road 471 MPK17-202 472 Palo Alto, CA 94303-4900 473 USA 474 Tel: +1 650 786 7503 475 Mail: Alain.Durand@sun.com 476 Internet Draft draft-ietf-ngtrans-broker-05.txt 478 Paolo Fasano S.p.A. 479 CSELT S.p.A. 480 Switching and Network Services - Networking 481 via G. Reiss Romoli, 274 482 10148 TORINO 483 Italy 484 Tel: +39 011 2285071 485 Mail: paolo.fasano@cselt.it 487 Ivano Guardini 488 CSELT S.p.A. 489 Switching and Network Services - Networking 490 via G. Reiss Romoli, 274 491 10148 TORINO 492 Italy 493 Tel: +39 011 2285424 494 Mail: ivano.guardini@cselt.it 496 Domenico Lento 497 TIM 498 Business Unit Project Management 499 via Orsini, 9 500 90100 Palermo 501 Italy 502 Tel: +39 091 7583243 503 Mail: dlento@mail.tim.it