idnits 2.17.1 draft-palet-v6ops-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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 559. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 575), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance 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 (June 10, 2004) is 7260 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) == Unused Reference: '13' is defined on line 503, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3068 (ref. '4') (Obsoleted by RFC 7526) == Outdated reference: A later version (-05) exists of draft-huitema-v6ops-teredo-01 == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-22 == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-02 == Outdated reference: A later version (-06) exists of draft-daniel-dhc-ipv6in4-opt-03 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-02 Summary: 6 errors (**), 0 flaws (~~), 10 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: December 9, 2004 Consulintel 4 P. Savola 5 CSC/FUNET 6 June 10, 2004 8 Analysis of IPv6 Tunnel End-point Discovery Mechanisms 9 draft-palet-v6ops-tun-auto-disc-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I 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 December 9, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 Tunneling is commonly used in several IPv6 transition mechanisms. To 43 be able to automate setting up tunnels, one critical component is 44 being able to automatically determine the tunnel end-point for the 45 tunneling mechanism. This memo analyses the different approaches for 46 configuring the IPv6 tunnel endpoint on a node. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Scenarios for Tunnel Endpoint Discovery . . . . . . . . . . . 3 52 2.1 Scenario 1: Initial IPv6 Deployment Stage . . . . . . . . 3 53 2.2 Scenario 2: Initial IPv6 Support from External ISP . . . . 4 54 2.3 Scenario 3: Nomadic Users . . . . . . . . . . . . . . . . 4 55 2.4 Scenario 4: Advanced IPv6 Deployment Stage . . . . . . . . 5 56 3. Analysis of Solutions . . . . . . . . . . . . . . . . . . . . 5 57 3.1 Shared-unicast -based Solutions . . . . . . . . . . . . . 5 58 3.2 Centralized Broker-based Solutions . . . . . . . . . . . . 6 59 3.3 DNS-based Solutions . . . . . . . . . . . . . . . . . . . 6 60 3.3.1 Prefixing the DNS Search Path . . . . . . . . . . . . 7 61 3.4 DHCP-based Solutions . . . . . . . . . . . . . . . . . . . 8 62 3.5 PPP-based Solutions . . . . . . . . . . . . . . . . . . . 9 63 3.6 Combined Solutions . . . . . . . . . . . . . . . . . . . . 9 64 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 68 8. Informative References . . . . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 70 Intellectual Property and Copyright Statements . . . . . . . . 13 72 1. Introduction 74 Tunneling is commonly used in several IPv6 transition mechanisms. It 75 is critically important to make setting up IPv6 connectivity simpler, 76 so that it can be done simply also by IPv6-ignorant, novice users, or 77 even completely transparently, without the user even having to know 78 that IPv6 connectivity has been obtained. 80 One critical piece in the automated set-up is discovering the 81 end-point for the IPv6-in-IPv4 (or possibly in the future, 82 IPv4-in-IPv6) tunnel. Note that the other end-point ("tunnel 83 server") typically also needs to have a means to configure the 84 client's end-point, but that is assumed to be transition mechanism 85 specific, and beyond the scope of this memo. A solution is being 86 designed [1] based on the tunnel server/broker concept [2] which 87 will, in particular, require this kind of discovery. 89 Many already-specified mechanisms already include a form of 90 auto-discovery: for example, 6to4 [3] uses global anycast [4] and/or 91 vendor's branch of DNS, Teredo [5] uses vendor's branch of DNS, and 92 ISATAP [6] uses search-path -prefixed DNS. 94 2. Scenarios for Tunnel Endpoint Discovery 96 At least three scenarios can be identified where tunnel endpoint 97 discovery would be useful. 99 2.1 Scenario 1: Initial IPv6 Deployment Stage 101 During the initial IPv6 deployment stage, the ISPs may not provide 102 native IPv6 connectivity, at least in the access network. However, 103 the ISP might offer IPv6 connectivity (probably for free) through an 104 automatically set-up tunnel. 106 In this scenario, the users (or rather, their operating systems) need 107 to be capable of automatically detecting whether the user's ISP is 108 offering such service or not, and setting up the tunnel if available. 110 If this kind of IPv6 connectivity is set up automatically, it could 111 create a load on the ISP's equipment which is configured as the 112 tunnel-endpoint (e.g., a tunnel server). This is particularly 113 important if state needs to be maintained. To address this 114 consideration, the discovery method should allow for multiple 115 end-points within a domain or even including a load-balancing 116 mechanism. 118 2.2 Scenario 2: Initial IPv6 Support from External ISP 120 During the initial IPv6 deployment stage, the ISPs might not support 121 IPv6 at all; there are thousands of ISPs, and many certainly won't be 122 supporting IPv6 any time soon. The customers of those ISPs then have 123 to use automatic tunneling mechanisms such as 6to4 or Teredo, or get 124 a third-party ISP for IPv6 connectivity. 126 In this scenario, the users (in general their operating systems) may 127 have a capability of automatically selecting a third-party ISP which 128 is servicing outsiders. The service is often free of charge. The 129 discovery process could either detect the closest serving end-point, 130 or pick the one manually configured by the user. 132 Given the fact that IPv6 service could be offered by third parties, 133 some kind of authentication could be required in order to allow only 134 registered customers to use the IPv6 service. The authentication 135 method will depend on the transition mechanism, so it is out of scope 136 of this memo. 138 TBD: should this scenario be removed? Third party ISPs may be not 139 economically feasible for free, even if there is some limited 140 deployment of them at the moment. But it could be a registered and 141 paid external service, for example a roaming service agreed among 142 differnt ISPs. 144 2.3 Scenario 3: Nomadic Users 146 Nomadic users require connectivity to Internet from everywhere, from 147 different locations: meetings, conferences, holidays, etc. Under 148 this circumstance (always) obtaining native IPv6 connectivity is not 149 feasible. The user has two choices: to discover a local tunnel (with 150 different IPv6 addresses and prefixes) if provided by the local ISP, 151 or to connect to the "home ISP" or "home network", implying the 152 possibility of keeping the same addresses. 154 A local tunnel is typically a preferable choice, and could also be 155 used as a Mobile IPv6 [7] care-of address. However, in many cases, 156 the local ISP may not be providing a tunnel service. 158 Connecting to a "home provider" to obtain the tunnel is typically a 159 safe choice, provided that the "home provider" allows IPv4 addresses 160 outside its own domain to use its tunnel services; at the very least, 161 typically this will require some sort of authentication. However, 162 especially when roaming on a different continent as the home network, 163 the latencies, etc., may be undesirable, so one might want to keep 164 this only as a backup option in case other approaches fail. 166 The whole process for having a new IPv6 tunnel with a new provider 167 should be as transparent as possible in order to avoid that users 168 need to manually re-register or change the configuration in their 169 host. It would be desirable that the architecture enables the users 170 to get connected and re-connected to the nearest tunnel end-point 171 without manual intervention (for example when moving). 173 2.4 Scenario 4: Advanced IPv6 Deployment Stage 175 When the IPv6 deployment is in a more advanced stage, namely more 176 users in more places looking for IPv6 connectivity, it is possible 177 that ISPs providing IPv6 connectivity need to start a broader 178 deployment. For a best IPv6 service, it is feasible that they 179 increase the performance by using a tunnel end-point cluster 180 geographically distributed to cover a country, etc. Furthermore they 181 could offer the users only one of the methods proposed below for 182 accessing the IPv6 connectivity. Each time users get IPv6 183 connectivity, they could use the same accesing method but they could 184 be assigned to different tunnel end-point belonging the cluster. 186 Under this schema, some kind of load balancing could be required in 187 order to distribute the load among the ISP resources. 189 In order to let all the candidate tunnel end-points to know the 190 configuration of the previous user’s tunnels, some kind of tunnel 191 management should be defined. However it is strongly dependant on 192 the transition mechanism used, so it is out of the scope of this 193 document. 195 In any case, as stated before, the whole process for obtaining a new 196 IPv6 tunnel with a new TS should be as much transparent as possible 197 in order to avoid that users need to manually re-register or change 198 the configuration in their host. It would be desirable that the 199 architecture makes the users get connected and re-connected to the 200 nearest tunnel end-point without manual intervention. 202 3. Analysis of Solutions 204 Several possible solutions to discovering the tunnel end-point can be 205 imagined; this section describes them in detail. 207 3.1 Shared-unicast -based Solutions 209 An "anycast" (shared-unicast by some terminology: see [8]) address 210 identifies a group of hosts, usually server hosts. When a client 211 sends a datagram to a shared-unicast address, it is delivered to one 212 of the shared-unicast servers based on the routing topology and 213 metrics. 215 There are two possible ways of using "anycast": as a global service 216 -- where a shared-unicast prefix is the same for everyone, and 217 advertised in the Inter-domain routing -- or as a local service, 218 where the service provider is sharing one of its own addresses on 219 multiple nodes for example for load-balancing or redundancy reasons. 221 Global "anycast" might be best applicable in scenario 2 -- to 222 automatically discover the closest serving third party ISP. However, 223 this raises the question of feasibility of that scenario. Local 224 "anycast" can be combined with other solutions, described later, to 225 seamlessly provide multiple tunnel end-points inside a single domain. 227 A packet to a shared-unicast address may end up being delivered to 228 more than one node. In addition, there is no guarantee that two 229 consecutive datagrams sent from the same host towards the same 230 shared-unicast address are going to be delivered to the same node. 231 However, when the routing topology is stable and metrics are 232 well-designed, the packets are regularly delivered to the same nodes. 234 It is also possible to only use an "anycast" address only for the 235 initial handshake, to establish a stable unicast address of the 236 end-point and to perform some initial negotiation (an example of such 237 is described in [9]). 239 3.2 Centralized Broker-based Solutions 241 Inside a single administrative domain, it would also be possible to 242 deploy a centralized server or a "broker", which should know, 243 probably in real-time, the status of all the associated end-points. 244 Furthermore, it could, by using some means, redirect the users the 245 correct end-points. This mechanism would still need another 246 complementary approach to find the centralized broker. 248 This approach is highly assumptive of the tunneling set-up mechanism, 249 and likely requires the implementation of lengthy redirection/ 250 negotiation features. As such, its applicability is not further 251 analyzed here. 253 Applying a centralized model over multiple administrative domains, 254 e.g., having a single server for the whole Internet, would be 255 administratively and management-wise unfeasible. Nevertheless, 256 agreements between several domains could make possible sophisticated 257 models 259 3.3 DNS-based Solutions 261 As DNS is globally deployed and easy to use, it could provide a means 262 for discovering the end-point address. 264 There are roughly three kinds of different approaches with DNS-based 265 discovery: 267 1. "global name": the systems look up a globally unique name, like 268 www.tunnel-server.net. -- this could be applicable with 269 (unfeasible) global inter-domain broker or anycast-based 270 solutions, and is therefore not considered at more length. 272 2. "vendor branch": the operating system vendors may provide a DNS 273 record which is looked up (e.g., "6to4.windows.microsoft.com."), 274 giving the vendor some control over already deployed systems. 275 This is typically only feasible to configure a global anycast 276 address, or provide the address of the vendor's own service, and 277 is not applicable in a multi-vendor environment, and is not 278 considered further. 280 3. "prefixing the search path" [10]: one could look up a 281 service-specific special string, like "_tunnel-server", appended 282 by the DNS search path, e.g., "isp.example.com", resulting in a 283 query of "_tunnel-server.isp.example.com". This assumes that the 284 DNS search path is provided by the ISP, and used by the user; 285 this applies to most users (advanced users may have their own 286 domainnames, own DNS servers, etc., but those could be expected 287 to manually configure the end-point information). This is the 288 most interesting approach, explored at more length below. 290 The special string could be more complex and make reference somehow 291 to the transition mechanism it will accept, i.e. 6to4_tunnel-server, 292 6in4_tunnel-server, teredo_tunnel-server, any_tunnel-server and so 293 on. 295 All of these approaches are typically coupled with a manual override 296 option, which can be used by the knowledgeable users to look up 297 different names or to specify the IP address completely. 299 3.3.1 Prefixing the DNS Search Path 301 Prefixing the search path bears a bit more analysis. There a couple 302 of fundamental questions: where to store the records (i.e., the 303 prefix to use, and what to do with the conflicts), and how to store 304 the information (i.e., whether to use A/AAAA records, other other 305 records). 307 There are at least three concrete possibilities for how to store the 308 information: 310 1. "A/AAAA/CNAME records": one could use just the regular records 311 for storing the end-point address or name. A drawback is that 312 there is a slightly higher probability of collision, depending on 313 the service identifier used. The advantage is that it's very 314 simple to implement and use. This also doesn't offer advanced 315 load-balancing features, beyond those already provided by DNS 316 round-robin techniques [11]. 318 2. "SRV records": SRV records were created specifically for service 319 discovery and load-balancing, mainly as a means to provide the 320 users (also external users) knowledge of services within a 321 domain. Quite this amount of unambiguity would not be needed if 322 the service identifier is unique enough and only used internally. 323 A slight drawback is that SRV records require slightly more 324 implementation and possibly more round-trips (if the results 325 aren't cached). 327 3. "NAPTR records": NAPTR records provide even more flexibility than 328 SRV records. The drawback is even more implementation and more 329 round-trips. TBD: needs more text. 331 The question of where to store the information has a few tradeoffs, 332 also depending on how the information is being stored. Using a 333 commonly used name as a service identifier coupled with A/AAAA 334 records would likely lead to false positives. On the other hand, if 335 a a prefix like '_tunnel-server' would be chosen, it would be quite 336 unprobable that conflicts would appear in practise. It is also worth 337 remembering that the result of a false positive -- i.e., getting an 338 address which is not a valid end-point -- is not necessarily a huge 339 problem because it's only an indicator that such service didn't exist 340 in the domain, as long as the tunneling mechanism can recover from 341 that scenario. 343 Another consideration is the deployment of wildcard DNS records. If 344 A/AAAA records were to be used, such records might create false 345 positives quite easily. Fortunately, wildcards are commonly deployed 346 only for MX records. A benefit of using SRV records is that they use 347 an additional level in the zones, like: 348 _tunnel-server._udp.isp.example.com." -- this would prevent a 349 wildcard record "*.isp.example.com" from harassing the discovery of 350 the end-point. XXX: needs to be checked. 352 3.4 DHCP-based Solutions 354 In most situations, the users receive the IPv4 information by means 355 of an IPv4 DHCP server. Consequently, one of the parameters to be 356 provided by the DHCP server could be the tunnel end-point address, 357 e.g., as described in [12]. 359 This approach has several drawbacks: 361 o It requires upgrading the DHCP client/server implementations to 362 support this feature. 364 o It is restricted to the local ISP. That is, it will not be 365 effective if the local ISP doesn't provide this parameter. This 366 could be also be an advantage considering that the this would only 367 support the tunnels provided by the local ISP, which would 368 probably be of good quality. 370 o It will not work if DHCP client is not used. DHCP is omitted 371 especially in many dial-up scenarios, where only PPP is used; DHCP 372 is not used in some (advanced) xDSL setups which use static 373 routing. Also, some managed networks do not use DHCP. Still, in 374 many cases, DHCP is used between a customer and the ISP. 376 o If a router is providing local DHCP information (e.g., an ADSL 377 router), the tunnel end-point information would have to be 378 automatically proxied to the "local DHCP", or manually configured 379 on the router to propagate to the hosts in the case that the 380 router is not activating the tunnel itself. 382 o It requires manual configuration/update of the ISP's DHCP servers 383 when there are changes to the tunnel end-points, similar to 384 updating DNS, NTP, etc. servers. 386 3.5 PPP-based Solutions 388 In the case of PPP-like connections, specific PPP parameters could be 389 passed to the clients, as part of the AAA signaling process. This 390 solution has the same drawbacks (and advantages) as indicated for the 391 DHCP-based solution. Further, there has been resistance to making 392 extensions to PPP (e.g., passing IPv6 prefix options), so it is an 393 open question whether this information could be passed as a 394 standardized PPP option at all. 396 3.6 Combined Solutions 398 There is a particularly interesting combination: DNS-lookups with a 399 service identifier combined with the DNS search path (particularly 400 with A/AAAA/CNAME records), and shared-unicast. DNS lookups can 401 provide a local IP address (or addresses) for the end-points, and the 402 local "anycast" approach can be used for load-balancing or adding 403 more end-points to the system transparently so that every user uses 404 the topologically closest end-point. 406 Similar approach to "anycasting" the end-point address obviously also 407 work for "anycast" and DHCP or PPP -based solutions. 409 4. Conclusions 411 DNS appears to be the simplest means to achieve end-point discovery; 412 DHCP and PPP have drawbacks and due to many scenarios where only one 413 of them is used, both the solutions would be needed. Inter-domain 414 anycast model appears to be practically unfeasible even if it could 415 work especially if "anycast" was only used for the unicast address 416 discovery. 418 In the DNS, the records could be stored either in A/AAAA/CNAME or SRV 419 records. The former appears to be slightly advantageous, while the 420 latter is provably correct and offers slightly better load-balancing 421 features, rather than a simple round-robin (and whatever may be 422 obtained using e.g., anycast). Further analysis is still needed on 423 the tradeoffs of these approaches. 425 Local anycasting techniques using a shared-unicast address (or 426 addresses) appear to be the most practical means for redundancy and 427 load-balancing. 429 5. Security Considerations 431 If the tunnel end-point discovery is done in an insecure fashion, so 432 that an attacker could influence the discovery process, the attacker 433 could be able to hijack all the IPv6 communications. This must be 434 kept in mind when analyzing the different discovery solutions, and 435 spelled out explicitly in the requirements if the threats are to be 436 mitigated in tunneling mechanisms somehow (e.g., using a return 437 routability procedures). 439 In particular, the potential weaknesses of DNS bear some 440 consideration. 442 6. IANA Considerations 444 This document requests no action for IANA. 446 [[note to RFC-editor: this section can be removed upon publication.]] 448 7. Acknowledgements 450 This memo was written as a consequence of real experience using IPv6 451 when traveling, number of talks during IETF meetings and specially 452 the work with the unmanaged, ISP and enterprise v6ops design teams. 453 The authors would also like to acknowledge the European Commission 454 support in the co-funding of the Euro6IX project, where this work is 455 being developed. 457 8 Informative References 459 [1] Durand, A. and F. Parent, "Requirements for assisted 460 tunneling", 461 draft-durand-v6ops-assisted-tunneling-requirements-00 (work in 462 progress), March 2004. 464 [2] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel 465 Broker", RFC 3053, January 2001. 467 [3] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 468 IPv4 Clouds", RFC 3056, February 2001. 470 [4] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 471 3068, June 2001. 473 [5] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", 474 draft-huitema-v6ops-teredo-01 (work in progress), February 475 2004. 477 [6] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site 478 Automatic Tunnel Addressing Protocol (ISATAP)", 479 draft-ietf-ngtrans-isatap-22 (work in progress), May 2004. 481 [7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 482 IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 483 2003. 485 [8] Hagino, J. and K. Ettican, "An analysis of IPv6 anycast", 486 draft-ietf-ipngwg-ipv6-anycast-analysis-02 (work in progress), 487 June 2003. 489 [9] Thaler, D. and L. Vicisano, "IPv4 Automatic Multicast Without 490 Explicit Tunnels (AMT)", draft-ietf-mboned-auto-multicast-02 491 (work in progress), February 2004. 493 [10] Faltstrom, P., "Design Choices When Expanding DNS", 494 draft-ymbk-dns-choices-00 (work in progress), May 2004. 496 [11] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 497 1995. 499 [12] Kim, P. and S. Park, "DHCP Option for Configuring IPv6-in-IPv4 500 Tunnels", draft-daniel-dhc-ipv6in4-opt-03 (work in progress), 501 April 2004. 503 [13] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 504 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 (work in 505 progress), February 2004. 507 Authors' Addresses 509 Jordi Palet Martinez 510 Consulintel 511 San Jose Artesano, 1 512 Alcobendas - Madrid 513 E-28108 - Spain 515 Phone: +34 91 151 81 99 516 Fax: +34 91 151 81 98 517 EMail: jordi.palet@consulintel.es 519 Miguel Angel Diaz Fernandez 520 Consulintel 521 San Jose Artesano, 1 522 Alcobendas - Madrid 523 E-28108 - Spain 525 Phone: +34 91 151 81 99 526 Fax: +34 91 151 81 98 527 EMail: miguelangel.diaz@consulintel.es 529 Pekka Savola 530 CSC/FUNET 532 Espoo 533 Finland 535 EMail: psavola@funet.fi 537 Intellectual Property Statement 539 The IETF takes no position regarding the validity or scope of any 540 Intellectual Property Rights or other rights that might be claimed to 541 pertain to the implementation or use of the technology described in 542 this document or the extent to which any license under such rights 543 might or might not be available; nor does it represent that it has 544 made any independent effort to identify any such rights. Information 545 on the procedures with respect to rights in RFC documents can be 546 found in BCP 78 and BCP 79. 548 Copies of IPR disclosures made to the IETF Secretariat and any 549 assurances of licenses to be made available, or the result of an 550 attempt made to obtain a general license or permission for the use of 551 such proprietary rights by implementers or users of this 552 specification can be obtained from the IETF on-line IPR repository at 553 http://www.ietf.org/ipr. 555 The IETF invites any interested party to bring to its attention any 556 copyrights, patents or patent applications, or other proprietary 557 rights that may cover technology that may be required to implement 558 this standard. Please address the information to the IETF at 559 ietf-ipr@ietf.org. 561 Disclaimer of Validity 563 This document and the information contained herein are provided on an 564 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 565 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 566 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 567 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 568 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 569 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 571 Copyright Statement 573 Copyright (C) The Internet Society (2004). This document is subject 574 to the rights, licenses and restrictions contained in BCP 78, and 575 except as set forth therein, the authors retain all their rights. 577 Acknowledgment 579 Funding for the RFC Editor function is currently provided by the 580 Internet Society.