idnits 2.17.1 draft-palet-v6ops-solution-tun-auto-disc-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.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 640. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 5) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 19 characters in excess of 72. == There are 18 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 (October 24, 2004) is 7095 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 (-03) exists of draft-palet-v6ops-tun-auto-disc-01 == Outdated reference: A later version (-08) exists of draft-iab-dns-choices-00 -- Obsolete informational reference (is this intentional?): RFC 3068 (ref. '5') (Obsoleted by RFC 7526) == Outdated reference: A later version (-02) exists of draft-palet-v6ops-auto-trans-01 == Outdated reference: A later version (-06) exists of draft-daniel-dhc-ipv6in4-opt-05 Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Palet 2 Internet-Draft M. Diaz 3 Expires: April 24, 2005 Consulintel 4 October 24, 2004 6 IPv6 Tunnel End-point Automatic Discovery Mechanism 7 draft-palet-v6ops-solution-tun-auto-disc-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 24, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 Tunneling is commonly used by several IPv6 transition mechanisms. To 43 be able to automate setting up tunnels, one critical component is a 44 solution to automatically discover the tunnel end-point (TEP) for the 45 transition mechanism. 47 This memo proposes a solution for discovering the IPv6 TEP in a 48 simple an efficient way. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Overview and Rationale . . . . . . . . . . . . . . . . . . . . 4 54 3. Solution Implementation . . . . . . . . . . . . . . . . . . . 4 55 3.1 SRV RR . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2 A/CNAME RR for Unicast . . . . . . . . . . . . . . . . . . 5 57 3.3 Shared Anycast . . . . . . . . . . . . . . . . . . . . . . 6 58 4. Solution Description . . . . . . . . . . . . . . . . . . . . . 6 59 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 5.1 ISP offering transition service(s) with SRV support on 61 its DNS server . . . . . . . . . . . . . . . . . . . . . . 8 62 5.2 ISP offering transition service(s) without SRV support 63 on its DNS server . . . . . . . . . . . . . . . . . . . . 9 64 5.3 ISP offering transition service(s) by means of third 65 parties . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.4 ISP offering transition service(s) only to own 67 customers . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.5 ISP offering transition service(s) to external users . . . 10 69 5.6 ISP does not offer transition service at all . . . . . . . 10 70 5.7 Increased Scalability and Automation . . . . . . . . . . . 11 71 6. Alternative DHCP-based Solution . . . . . . . . . . . . . . . 11 72 7. Service Names for Transition Mechanisms . . . . . . . . . . . 12 73 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 76 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 79 12.2 Informative References . . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 81 Intellectual Property and Copyright Statements . . . . . . . . 15 83 1. Introduction 85 During the IPv6 transition stage, it is foreseen that different 86 transition mechanisms are used. Most of them are tunnel-based and it 87 is critically important to ensure that the setup of the IPv6 88 connectivity is simple, so that it can be done also by non-technical 89 users, or even completely transparently, without the user recognizing 90 that IPv6 connectivity has been obtained. 92 A critical piece in the automated set-up is discovering the tunnel 93 end-point (TEP), also known as tunnel-server (TS), for the transition 94 mechanism that will be used by the client (or rather, their operating 95 system). Note that the tunnel end-point at the server side (TS) 96 typically also needs to have a mean to configure the client (tunnel) 97 end-point, but that is assumed to be transition mechanism specific, 98 and beyond the scope of this memo. 100 In this memo an elegant and simple solution for the TEP 101 auto-discovery is described, which fits in all the scenarios analyzed 102 in [1]. The solution offers the following features: 104 1. It is simple. 106 2. It can be easily deployed. 108 3. It is scalable. 110 4. It is topologically correct: Provides the nearest TEP to the user 111 in terms of IP hops. 113 5. Applies to all the existing transition mechanisms (and possibly 114 future ones), without any need for modifying them. 116 6. It is based on a combination of DNS and anycast (shared unicast 117 according to some terminology [2]) approach. 119 7. It offers certain degree of redundancy: It would work if either 120 the DNS or the anycast support fail. 122 8. It offers load balancing capability in order to share all the 123 known TEPs among all the clients willing to get IPv6 connectivity 124 through them. 126 9. It is fast and does not add significant overhead into the 127 transition mechanism setup process. 129 2. Overview and Rationale 131 As pointed out at [1], the DNS is globally deployed and easy to use. 132 By means of prefixing the search path one can look up for a specific 133 service that is a specific TEP or transition mechanism server [3]. 135 On the other hand, shared anycast is also a very useful approach 136 since it can globally identify a specific service (TEP or transition 137 mechanism). It is even easier and simpler than the DNS approach. 138 However anycast routes not always are well configured and stable, so 139 connection with the server belonging to an anycast group might not be 140 always possible, which means that is not necessarily the most 141 topologically correct. Moreover, consecutive datagrams sent from the 142 same host towards the same anycast address have no guarantee at all 143 that they are going to be delivered to the same anycast node. 145 For this reason, the anycast approach is only considered as a 146 complementary backup solution when prefixing the search path on DNS 147 has negative replies. 149 In addition, both approaches offer the possibility of pointing 150 directly to the TEP or alternatively to an intermediate node (i.e. 151 Tunnel Broker, TB) where to start the signaling handshake for setting 152 up the tunnel. 154 The idea that the auto-discovery solution exploits is that the client 155 willing to use a transition mechanism will first make one or several 156 DNS queries. The DNS will redirect to a TEP (or alternatively a TB 157 if more sophistication is required) located within the ISP or a third 158 party (other near ISP, roaming TEP service, etc.), if possible. 159 Alternatively, the DNS could also reply with an anycast address for 160 the searched TEP. 162 The solution consequently makes use of existing protocols, not 163 requiring modifications or any new protocol. 165 Details of how the DNS queries are made and how the prefix search 166 path is used are presented below. 168 3. Solution Implementation 170 The solution requires the implementation, at the ISP willing to offer 171 the service, of one or several new configurations of existing 172 services (namely DNS and anycast), as explained in the following 173 sub-sections. 175 Note that the solution will work with just of those configurations, 176 but all them together provide a more complete approach, which is 177 better explained looking at the Case Studies section. 179 For the client is required that the three are actually implemented, 180 in the sequence below introduced, so the client will always succed, 181 regardless of what the ISP to which they are connected actually has 182 configured. 184 3.1 SRV RR 186 The DNS server of the ISP deploying a specific transition mechanism 187 should use SRV RR to announce the transition mechanism service. 189 According to [4] the SRV RR for a specific transition mechanism 190 should have the following format: 192 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 194 Please refer to [4] for a detailed explanation of each field in DNS 195 SRV RRs. 197 The service name for the auto-discovery purpose should be 198 standardized for each transition mechanism. 200 _transition-mechanism_srv._protocol.ispname.com 202 (assuming that the domain name of a ISP is ispname.com). 204 For example the records for 6in4, tsp, teredo, isatap and 6to4 would 205 result: _6in4_srv._ipv4.ispname.com, _tsp_srv._tcp.ispname.com, 206 _teredo_srv._udp.ispname.com, _isatap_srv._ipv4.ispname.com, 207 _6to4_srv._ipv4.ispname.com, etc. 209 Some illustrative examples of specific transition mechanisms 210 configured as SRV RRs in the DNS server are: 212 _6to4_srv._ipv4 SRV 0 1 10000 server1.ispname.com 213 _tsp_srv._tcp SRV 1 2 80 server2.ispname.com 214 _teredo_srv._udp SRV 2 1 3456 server3.ispname.com 216 3.2 A/CNAME RR for Unicast 218 A standardized A/CNAME RR for each supported transition mechanisms 219 within the domain of the ISP, using the same nomenclature as 220 introduced in the previous section, in the form: 222 _transition-mechanism_srv._protocol.ispname.com 223 (assuming that the domain name of a ISP is ispname.com). 225 For example the records for 6in4, tsp, teredo, isatap and 6to4 would 226 result: _6in4_srv._ipv4.ispname.com, _tsp_srv._tcp.ispname.com, 227 _teredo_srv._udp.ispname.com, _isatap_srv._ipv4.ispname.com, 228 _6to4_srv._ipv4.ispname.com, etc. 230 Note: The use of the underscore character minimizes the probability 231 of conflict with DNS names already defined. 233 3.3 Shared Anycast 235 Each transition mechanism could have assigned and implemented a 236 shared anycast address, such as in the case of the 6to4 transition 237 mechanism [5]. 239 The anycast prefix/address for each transition mechanism is listed 240 below (TBD by IANA): 242 Transition Mechanism Anycast Prefix/Adddress 244 TBD 246 4. Solution Description 248 The ideal situation is to implement all the points indicated in the 249 previous section. Under that scenario, the auto-discovery mechanism 250 would offer the best functionality and all the features described 251 above. 253 However, it is not mandatory that all them are fulfilled in order to 254 provide a functional auto-discovery mechanism, but at least one must 255 be implemented. In this way the auto-discovery mechanism will work 256 during all the deployment stages (auto-discovery not yet 257 standardized, auto-discovery already standardized but less deployed, 258 auto-discovery highly deployed). As many are implemented, more 259 functional the auto-discovery mechanism is. 261 When looking for a specific TEP within the ISP the user belongs to, 262 the first step is always the same because the user does not know (and 263 neither has to know) which is the transition mechanism deployment 264 status within its ISP, so the application/stack always query firstly 265 for a DNS SRV RR to its ISP DNS server. 267 To do that, the ISP's domain name is essential for prefixing the DNS 268 search path, so the client (or rather the operating system) firstly 269 learns the domain name of the ISP. There are several ways to do it, 270 but in general it will be learned by making NS RR queries to the DNS. 272 The ISP's domain name will be the base string for the prefixing of 273 the DNS search path. Once the client has discovered it, a first 274 attempt to find the TEP of the specific transition mechanism is made 275 by building a SRV RR query (i.e. _tsp_srv._tcp.ispname.com) to the 276 DNS server belonging to the ISP. 278 Next it is shown an example of how the DNS SRV RRs would be used to 279 query the ISP DNS server. To discover the specific TEP within the 280 ISP domain (say, ispname.com), the client (rather the operating 281 system) makes a DNS query [6][7] for 282 QNAME=_teredo_srv._udp.ispname.com, QCLASS=IN, and QTYPE=SRV 284 If the DNS server matches the query, it returns the proper reply with 285 all the possible targets defined for that query, so the client will 286 receive a list of DNS SRV RRs in a DNS reply, which gives all the 287 teredo TEPs in the ISP domain ispname.com, such as: 289 ;; Priority Weight Port Target 290 _teredo_srv._udp.ispname.com IN SRV 0 0 4500 tep1.ispname.com 291 _teredo_srv._udp.ispname.com IN SRV 0 1 4000 tep2.ispname.com 292 _teredo_srv._udp.ispname.com IN SRV 1 0 5000 host.other_ispname.com 293 _teredo_srv._udp.ispname.com IN SRV 2 0 5000 tepnode.other-domain.com 295 When there are more than one TEP, all of them could be assigned with 296 different priority and weight parameters in order to do load 297 balancing. Even some of them could be located outside the ISP. The 298 client will try all the obtained TEP according to the SRV RR 299 information (priority and weight) until it gets connected to one of 300 them. At this point the auto-discovery function ends. 302 If no DNS SRV RR reply is obtained (either because the DNS 303 administrator did not created DNS SRV RR entries for the requested 304 transition mechanism or either the DNS server or client resolver has 305 not SRV RR support), then an A/CNAME query is built by the client by 306 appending the standardized service name to the ISP domain name in 307 accordance with the what has been indicated at the "A/CNAME RR for 308 Anycast" section (i.e. _teredo_srv._udp.ispname.com). 310 Follows an example of how the DNS A/CNAME RRs would be used to query 311 the ISP DNS server. To discover the specific TEP within the ISP's 312 domain (say, ispname.com), the client (rather the operating system) 313 makes a DNS query [6][7] for QNAME=_teredo_srv._udp.ispname.com, 314 QCLASS=IN, and QTYPE=A or QTYPE=CNAME. 316 If there is a TEP deployed within the ISP (or a third party one), 317 then the DNS reply redirects the client to it and the auto-discovery 318 function ends in this point. 320 Finally if there is not a valid A/CNAME RR matching the client query, 321 then the client will directly refer to the standardized "Shared 322 Anycast" address regarding the searched TEP. This allows the 323 provision of the service, for free, by third parties, when the own 324 ISP does not provide it (i.e. nomadic users), and doesn't require 325 any configuration in the ISP infrastructure. In this point the 326 auto-discovery function ends. 328 Although by using the standardized shared anycast address the client 329 always will contact to one TEP (assuming BGP routes are well 330 configured, it could be within the own-ISP infrastructure), the use 331 of the shared anycast address is preferred as the last option after 332 DNS SRV RR and DNS A/CNAME RR fails. This is because by means of DNS 333 RR, administrators will always configure nearest TEP hosts (within 334 the client ISP) for own-customers and load balancing can be better 335 done (in case of DNS SRV RR). Consequently, the shared anycast 336 option is used only as backup solution and also to provide service to 337 external users. 339 5. Case Studies 341 In order to clarify the behavior of this solution, some case studies 342 are presented below. It also shows how flexible is the solution and 343 how it can be used depending on the deployment stage at the ISP or 344 even its willingness to provide service only to own-customers or 345 external ones. 347 5.1 ISP offering transition service(s) with SRV support on its DNS 348 server 350 Many ISPs could offer IPv6 transition service(s) by deploying one or 351 several TEPs in its own infrastructure. It is also possible that 352 ISPs are interested to offer IPv6 transition mechanisms by means of 353 third party agreements or even through well known and convenient 354 nearby TEPs or which are free of charge. 356 In this case, the ISP could setup the DNS server with SRV RRs with 357 the "Target" parameter pointing be the TEPs deployed either inside 358 that ISP or the third party one. Several SRV RRs can be configured 359 for each specific transition mechanism service available. 361 If the ISP DNS server has SRV RRs matching the client query, then it 362 will reply with all the SRV records matching that query. 364 The "Priority" parameter of the SRV record could be used to 365 prioritize the own TEPs. If the higher priority TEP does not 366 respond, the client will attempt the next one, and so on. 368 Some load balancing among TEPs is possible by using the "Weight" 369 field as suggested by [4]. 371 The standardized shared anycast address for each specific mechanism 372 TEP could be added as target to the DNS SRV RR. In that case it 373 should have the lowest priority in order to redirect the client 374 always to local TEP as a first option. 376 5.2 ISP offering transition service(s) without SRV support on its DNS 377 server 379 Even if unusual is possible that the DNS servers doesn't support SRV 380 RR or that the ISP does not wish to configure SRV RR, for whatever 381 reason. Even do, the ISP may be interested in offering transition 382 services to its customers, and several TEPs, for different transition 383 mechanism will be deployed. 385 In this case the best solution for announcing local TEPs within the 386 ISP is by means of DNS A/CNAME RR. Clients will always try to get a 387 valid DNS SRV RR reply, but once it fails a valid DNS SRV A/CNAME 388 will be queried. 390 However, in this case the load-balancing feature is somehow limited, 391 based only on round-robin RR techniques, according to the 392 capabilities of the DNS server. 394 5.3 ISP offering transition service(s) by means of third parties 396 In initial early deployment stages, it is possible that ISPs can not 397 offer this service by themselves (either because business 398 considerations or because lack of resources, knowledge, etc.).. 399 However, they can agree with third parties for offering the service 400 to theirs customers. They can even facilitate their customers the 401 auto-discovery of free TEPs located in other domains. 403 In this case, they can proceed as already indicated in the previous 404 cases which mention how a third party TEP can be announced by the 405 DNS. 407 5.4 ISP offering transition service(s) only to own customers 409 The solution indicated in the previous cases is available to any 410 client that use the a DNS server which has been configured to 411 advertise the TEPs, even to external users (non-customers) using that 412 DNS server. 414 If an ISP wants to ensure that only own-customers automatically 415 discover the advertised TEPs, it could configure the DNS server(s) to 416 send different replies (views), either DNS SRV or A/CNAME RRs, based 417 on the IP address of the incoming queries. 419 According to this, a SRV or A/CNAME RR query coming from a customer 420 (the IP will belong to the ISP allocations), could have a reply 421 containing the information regarding the requested TEPs deployed 422 within the ISP, the TEPs deployed by associated third parties, the 423 anycast address of the TEP or any combination of these options. On 424 the other hand, if the same query is coming from outside the ISP 425 network, then the DNS reply could only contain the TEPs deployed by 426 associated third parties or the anycast TEP or nothing. 428 Unlimited configurations are possible. This view functionality 429 strongly depends on the DNS server implementation that is being used 430 within the ISP. 432 Similarly the anycast advertising can be limited by proper 433 configuration of BGP, in order to avoid the TEPs being automatically 434 discovered by non-customers. 436 Avoiding the automatic discovery of the TEPs (by means of either DNS 437 or anycast) will actually not avoid them being used, but only its 438 auto-discovery, because they can be manually discovered/configured by 439 the users. But is also possible to limit the access to the TEPs by 440 means of filtering options, for example, to avoid any communication 441 being initiated to them by IP addresses not belonging to that ISP. 443 5.5 ISP offering transition service(s) to external users 445 If an ISP is willing to offer transition service(s) to external 446 customers, the best option for facilitating the auto-discovery of the 447 TEPs, is the configuration of the "Shared Anycast" as already 448 previously described, for each of the transition mechanism supported. 450 5.6 ISP does not offer transition service at all 452 In case an ISP does not deploy any transition mechanisms, and wish no 453 support their customers for using external services, they may 454 auto-discover available TEPs as indicated in the previous case. 456 In this case, the client willing to use a specific TEP firstly will 457 try to get a valid DNS SRV RR reply. However it will fail because 458 the ISP DNS server will not have any entry for it. Once it fails, a 459 DNS SRV A/CNAME will be also queried, which also will fail due to the 460 same reason. This is the expected behavior of the auto-discovery 461 mechanism and the reason for the Shared Anycast option. So, after 462 both types of DNS queries have failed, client will try the 463 standardized shared anycast address to get connected to the required 464 TEP, which will be located out the ISP network. 466 The only requirement for this to actually work, is that the ISP 467 routes to the standardized shared anycast addresses have to be 468 allowed within the ISP, so the foreign TEPs are reachable. This is 469 currently a the normal situation, fulfilled by most of the ISPs, as 470 proven with the 6to4 anycast address [5]. 472 5.7 Increased Scalability and Automation 474 In order to provide a more automated service, or even increased 475 scalability, a "Tunnel End-Broker" (TEB) service could be defined and 476 deployed. 478 The basic idea is to have a broker server (for instance 479 _teb_srv._ipv4.ispname.com) that will add more sophistication to the 480 system, but also increase the complexity of the implementation. In 481 this case, the transition mechanism will require a signaling higher 482 layer, that could also provide authenticated transition services and 483 enhanced roaming features. 485 In this scenario, the client will always try first _teb_srv._ipv4 486 (SRV, A/CNAME) or the corresponding anycast address, automatically 487 discover the adequate transition mechanism and the correct TEP, and 488 then pass the information to the transition mechanism itself to 489 establish the tunnel. 491 At this way, the auto-discovery may be complemented with the 492 auto-transition as described in [8]. 494 6. Alternative DHCP-based Solution 496 Although the use of DHCP options to provide the TEP [9] has some 497 drawbacks, as analyzed in [1], it is proven that in some scenarios it 498 is useful, so it could be considered as a backup solution under 499 certain scenarios when communication with the specific TEP is not 500 possible due to whatever reason. 502 Scenarios where DHCP applies are typically within enterprise 503 networks, and users could use the information provided by the DHCP 504 server to contact a 6in4 TEP. 506 In this way, DHCP is an alternative basically when the enterprise 507 wish to ensure a managed transition related to the DHCP usage, 508 instead of the ISP provision, and has no control over DNS and/or BGP 509 configurations. 511 7. Service Names for Transition Mechanisms 513 This section list the transition mechanisms and the service names to 514 be used: 516 Transition Mechanism Service Name 517 6in4 (RFCxxxx) 6in4 518 tsp (RFCxxxx) tsp 519 teredo (RFCxxxx) teredo 520 isatap (RFCxxxx) isatap 521 6to4 (RFCxxxx) 6to4 522 ... ... 524 TBD. 526 8. Conclusions 528 In order to take advantage of the auto-discovery solution, the 529 configuration scripts of the transition mechanisms should use the DNS 530 RRs introduced in this document, always preferring SRV versus 531 A/CNAME. Anycast could be used as the last option. 533 DNS views and filtering can be configured by ISPs to avoid the 534 auto-discovery working for non-customers and to avoid the access to 535 the TEPs by clients using IP addresses not belonging to the ISP. 537 Those ISPs willing to provide service to external users, should 538 properly configure Shared Anycast. 540 Can/should we use this document also for auto-discovering IPv4 in 541 IPv6 tunnels ? TBD. 543 9. Security Considerations 545 TBD. 547 10. IANA Considerations 549 Can we assign an anycast address for each transition mechanism ? TBD. 551 11. Acknowledgements 553 The authors would like to acknowledge inputs from Alvaro Vives, Pekka 554 Savola, Antonio Skarmeta and the European Commission support in the 555 co-funding of the Euro6IX project, where this work is being 556 developed. 558 12. References 560 12.1 Normative References 562 12.2 Informative References 564 [1] Palet, J. and M. Diaz, "Evaluation of v6ops Auto-discovery for 565 Tunneling Mechanisms", draft-palet-v6ops-tun-auto-disc-01 (work 566 in progress), June 2004. 568 [2] Hagino, J. and K. Ettican, "An analysis of IPv6 anycast", 569 draft-ietf-ipngwg-ipv6-anycast-analysis-02 (work in progress), 570 June 2003. 572 [3] Faltstrom, P. and R. Austein, "Design Choices When Expanding 573 DNS", draft-iab-dns-choices-00 (work in progress), October 2004. 575 [4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 576 specifying the location of services (DNS SRV)", RFC 2782, 577 February 2000. 579 [5] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 580 3068, June 2001. 582 [6] Mockapetris, P., "Domain names - concepts and facilities", STD 583 13, RFC 1034, November 1987. 585 [7] Mockapetris, P., "Domain names - implementation and 586 specification", STD 13, RFC 1035, November 1987. 588 [8] Palet, J. and M. Diaz, "Evaluation of IPv6 Auto-Transition 589 Algorithm", draft-palet-v6ops-auto-trans-01 (work in progress), 590 July 2004. 592 [9] Kim, P. and S. Park, "DHCP Option for Configuring IPv6-in-IPv4 593 Tunnels", draft-daniel-dhc-ipv6in4-opt-05 (work in progress), 594 October 2004. 596 Authors' Addresses 598 Jordi Palet Martinez 599 Consulintel 600 San Jose Artesano, 1 601 Alcobendas - Madrid 602 E-28108 - Spain 604 Phone: +34 91 151 81 99 605 Fax: +34 91 151 81 98 606 EMail: jordi.palet@consulintel.es 608 Miguel Angel Diaz Fernandez 609 Consulintel 610 San Jose Artesano, 1 611 Alcobendas - Madrid 612 E-28108 - Spain 614 Phone: +34 91 151 81 99 615 Fax: +34 91 151 81 98 616 EMail: miguelangel.diaz@consulintel.es 618 Intellectual Property Statement 620 The IETF takes no position regarding the validity or scope of any 621 Intellectual Property Rights or other rights that might be claimed to 622 pertain to the implementation or use of the technology described in 623 this document or the extent to which any license under such rights 624 might or might not be available; nor does it represent that it has 625 made any independent effort to identify any such rights. Information 626 on the procedures with respect to rights in RFC documents can be 627 found in BCP 78 and BCP 79. 629 Copies of IPR disclosures made to the IETF Secretariat and any 630 assurances of licenses to be made available, or the result of an 631 attempt made to obtain a general license or permission for the use of 632 such proprietary rights by implementers or users of this 633 specification can be obtained from the IETF on-line IPR repository at 634 http://www.ietf.org/ipr. 636 The IETF invites any interested party to bring to its attention any 637 copyrights, patents or patent applications, or other proprietary 638 rights that may cover technology that may be required to implement 639 this standard. Please address the information to the IETF at 640 ietf-ipr@ietf.org. 642 Disclaimer of Validity 644 This document and the information contained herein are provided on an 645 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 646 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 647 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 648 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 649 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 650 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 652 Copyright Statement 654 Copyright (C) The Internet Society (2004). This document is subject 655 to the rights, licenses and restrictions contained in BCP 78, and 656 except as set forth therein, the authors retain all their rights. 658 Acknowledgment 660 Funding for the RFC Editor function is currently provided by the 661 Internet Society.