idnits 2.17.1 draft-huitema-multi6-addr-selection-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 547. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 276: '... routers MUST advertise a null prefe...' 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 16, 2004) is 7124 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: '4' is defined on line 479, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '1') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '2') (Obsoleted by RFC 4862) ** Downref: Normative reference to an Informational RFC: RFC 3582 (ref. '4') ** Obsolete normative reference: RFC 3484 (ref. '5') (Obsoleted by RFC 6724) -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 3633 (ref. '7') (Obsoleted by RFC 8415) Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Huitema 2 Internet-Draft R. Draves 3 Expires: April 16, 2005 Microsoft 4 M. Bagnulo 5 UC3M 6 October 16, 2004 8 Address selection in multihomed environments 9 draft-huitema-multi6-addr-selection-00 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 16, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This note presents mechanisms for address selection in hosts within a 45 multihomed site. The goal of the presented mechanisms is to allow 46 hosts within the multihomed site to establish new communications 47 after an outage. The presented mechanisms are not by themselves a 48 complete multihoming solution but rather a component of such 49 solution. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Reference topology . . . . . . . . . . . . . . . . . . . . . . 4 55 3. The problem: address selection after failures . . . . . . . . 5 56 4. Goals and non-goals . . . . . . . . . . . . . . . . . . . . . 7 57 4.1 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4.2 Non goals . . . . . . . . . . . . . . . . . . . . . . . . 7 59 5. Proposed mechanisms . . . . . . . . . . . . . . . . . . . . . 8 60 5.1 Proactive mechanisms . . . . . . . . . . . . . . . . . . . 8 61 5.1.1 Direct link failures . . . . . . . . . . . . . . . . . 8 62 5.1.2 Other failure modes . . . . . . . . . . . . . . . . . 9 63 5.2 Reactive mechanisms . . . . . . . . . . . . . . . . . . . 11 64 6. Future steps . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 68 Intellectual Property and Copyright Statements . . . . . . . . 17 70 1. Introduction 72 A way to solve the issue of site multihoming is to have a separate 73 site prefix for each connection of the site, and to derive as many 74 addresses for each hosts. This approach to multi-homing, which we 75 call Host-Centric IPv6 Multihoming, has the advantage of minimal 76 impact on the inter-domain routing fabric, since each site prefix can 77 be aggregated within the larger prefix of a specific provider; 78 however, it opens a number of issues, that have to be addressed in 79 order to provide a multihoming solution compatible with such 80 addressing scheme. 82 In this memo we will present a set of mechanisms enable the hosts 83 within the multihomed site to select the addresses in order to be 84 able to establish new communications after an outage. The presented 85 mechanism are not by themselves a complete multihoming solution but 86 rather a component of such solution. 88 2. Reference topology 90 In the following discussion, we will use this reference topology: 92 /-- ( A ) ---( ) 93 X (site X) ( IPv6 ) ---(C)---(site Y)Y 94 \-- ( B ) ---( ) 96 The topology features two hosts, X and Y. The site of X is 97 multihomed while the site of Y is single homed. Host X has to global 98 IPv6 addresses, which we will note "A:X" and "B:X", formed by 99 combined the prefixes allocated by ISP A and B to "site X" with the 100 host identifier of X. Y has only one address "C:Y". 102 We assume that Y, when it starts engaging communication with X, has 103 learned the addresses A:X and B:X, for example because they were 104 published in the DNS. We do not assume that the DNS is dynamic: 105 there will be situations in which both A:X and B:X are published, 106 while in fact only one is reachable. We assume that X, when it 107 receives packets from Y, has only access to information contained in 108 the packet coming from Y, e.g. the source address; we do not assume 109 that X can retrieve by external means the set of addresses associated 110 to Y. similar assumptions are made when X is initiating the 111 communication, only that in this case, a single address i.e. C:Y is 112 published in the DNS 114 In this scenario, both ISPA and ISPB are performing ingress filtering 115 and have not relaxed the source address checks. So, we assume that 116 an ingress filtering compatibility mechanism is available at the 117 multihomed site (Site X) so that packets are forwarded through the 118 ISP that corresponds to the source address prefix included in the 119 packet by the host. 121 3. The problem: address selection after failures 123 In case that a failure occurs in one of the ISPs of the multihomed 124 site, it may not be possible to establish a new communication towards 125 a destination outside the site using any pair of addresses. For 126 instance, in the case that the link between ISPA and the Internet 127 fails, it will not be possible to establish a communication between X 128 and Y using address A:X. In this case, the communication will fail 129 in both directions: 131 - If Y tries to establish a communication with X using A:X as a 132 destination address, packets would be discarded because there is no 133 path available from the Internet to ISPA. 135 - If X tries to communicate with Y using A:X as a source address, 136 packets will be routed through ISPA in order to comply with ingress 137 filters, and because ISPA has no link available wit the rest of the 138 Internet, the packet will be discarded (it should be noted that even 139 if the packet could make it to Y, reply packets from Y to X would 140 contain A:X as a destination address, which is unreachable from Y). 142 So, in order to establish a communication between X and Y when a 143 failure has occurred in ISPA, the address derived from ISPA block 144 i.e. A:X, must not be used for the communication. 146 The solution for this problem has to be provided in the address 147 selection mechanisms. In particular, when the communication is 148 established from the host Y to the host X, the solution has to be 149 provided in the destination address selection mechanism at host Y and 150 when the communication is established from the host X to the host Y, 151 the solution has to be provided in the source address selection 152 mechanism at host X. Default address selection for IPv6 hosts is 153 specified in RFC 3484 [5] 155 We will first consider the support provided by RFC 3484 when the 156 communication is established from host Y to host X. In this case, 157 host Y has two possible destination addresses A:X and B:X. Without 158 any additional knowledge, both addresses are equivalent to host Y, so 159 the default destination address selection mechanism will return a 160 list of the two addresses ordered as they were returned by the 161 resolver. It may occur that A:X is first. In this case, host Y will 162 use A:X to reach host X and it will fail. At this point, RFC 3484 163 states that if there are other destination addresses available, the 164 application should retry to establish the communication, using the 165 next address in the list. If the application retries with address 166 B:X, the communication will be established successfully. 168 In conclusion, it seems that the current destination address 169 selection mechanism is enough to deal with this situation (as long as 170 applications retry with all the addresses). 172 Next, we will consider the support provided by RFC 3484 when the 173 communication is established from host X to host Y. In this case, 174 destination address selection performed in host X is trivial, since 175 there is only one address available for Y (C:Y). Source address 176 selection mechanism as specified in RFC 3484 will not prefer any of 177 the two source addresses if no additional information is available, 178 so any of the addresses can be selected as source address. In the 179 case that address A:X is selected, the communication will fail. In 180 this case there are no alternative destination address to retry with, 181 so the communication will definitely fail. 183 In conclusion, the source address selection mechanism defined in RFC 184 3484 is not enough to support this scenario. This memo defines 185 mechanisms to provide a solution for this case. 187 4. Goals and non-goals 189 4.1 Goal 191 The gaol of this memo is to provide mechanisms to complement the 192 source address selection of the host within the multihomed that allow 193 it to initiate new communications after an outage, without requiring 194 any modification to the hosts outside the multihomed site. 196 4.2 Non goals 198 It is not a goal of this memo to modify hosts located outside the 199 multihomed site. 201 It is not the goal of this memo to define a complete multihoming 202 solution, but rather to define a component of such solution. In 203 particular, is not the goal of this memo to define a mechanism to 204 preserve established communication. The presented mechanisms are to 205 be used for establishing new communications after an outage. Whether 206 the presented mechanisms are suitable for selecting a new address to 207 re-home an established communication after an outage is to be 208 considered in the future. In particular, the mechanisms presented in 209 this memo do not assume any mechanism available in the external host, 210 and this is likely to not be the case in a solution for preserving 211 established communications. 213 5. Proposed mechanisms 215 There are two types of mechanisms that can be used to enable the host 216 within the multihomed site to select the appropriate source address: 217 proactive mechanisms, where the host is notified about which source 218 address prefixes should be used for the different destinations and 219 reactive mechanisms, which are based on the trial and error approach, 220 where the hosts tries with different source address prefixes and 221 detects which one is available. 223 5.1 Proactive mechanisms 225 In this case, two mechanisms are needed: first, a mechanisms to 226 detect the outage and then a mechanisms to inform the host about 227 which prefixes should be used in the source address for the different 228 destinations. While this may seem a lot of information to be stored 229 in the host, it should be noted that in the default case, when no 230 outage has occurred, all prefixes can be used to reach all the 231 destinations, so no information is needed. When an outage occurs, 232 the host must be informed of which source address prefix should not 233 be used to reach a certain set of destinations. Depending on the 234 type of outage, the amount of information may vary. 236 We will first present mechanisms that can be used when the outage 237 occurs in the direct link between the multihomed site and the ISP and 238 then we will present a more general approach. 240 5.1.1 Direct link failures 242 In the case that the failure has occurred affecting the direct link 243 between the multihomed site and one of its ISP (let's say ISPA), the 244 prefix associated with that ISP should not be used for any new 245 communication, since the prefix is unreachable from any other part of 246 the Internet. 248 There are several mechanisms that can be used to detect the outage. 249 For instance, if any routing protocol is used between the ISP and the 250 multihomed site, such protocol can be used to detect the outage. In 251 any case, it is possible to use a periodic ICMP echo request for 252 detecting the outage on direct links. 254 In addition, we must establish a communication channel that quickly 255 signals these failures to the hosts. The logical channel to use is 256 the "router advertisement" message, which the routers use to 257 communicate to hosts the list of available prefixes. We propose here 258 to use the "preferred" and "valid" flags in these prefixes to signal 259 to hosts the addresses that should, or should not, be used as source 260 address at any given time. 262 The router advertisement messages are defined in [1] ; their use for 263 address configuration is defined in [2] . As specified in [1] , the 264 router advertisements include a variable number of Prefix Information 265 parameters. Each Prefix Information parameter specifies: 267 * an address prefix value, 268 * an "on-link" flag, used in neighbor discovery, 269 * an "autonomous" flag, used for autonomous address configuration, 270 * the "valid" lifetime, 271 * the "preferred" lifetime. 273 We propose to use the "preferred" lifetime to indicate whether 274 addresses derived from the prefix can be used as source address in 275 multihomed networks. When a prefix is temporarily not available 276 routers MUST advertise a null preferred lifetime for that prefix. 278 In conformance with section 5.5.4 of [1] , the hosts will notice 279 that the formerly preferred address becomes deprecated when its 280 preferred lifetime expires. They will not use the deprecated 281 addresses in new communications if an alternate (non-deprecated) 282 address is available and has sufficient scope. 284 This solution is sufficient when the site is composed of a single 285 link; for more complex sites with multiple subnets, we need a 286 mechanism with a broader scope than Router Advertisement. There are 287 two available candidates that provide the required fucntionality: the 288 router renumbering protocol and the prefix delegation option defined 289 for DHCP One option is to use Router Renumbering [3] protocol and 290 the other option is to use DHCP[7]. 292 In order to advertise a null preferred lifetime for a specific 293 prefix, the sites routers must be able to learn about that prefix. 294 Any of the two proposed protocols, Router Renumbering or DHCP Prefix 295 Delegation can be used to pass this information. These protocols 296 allow an authorized agent, in that case the egress site, to update 297 the list of prefixes advertised by the site's routers. The protocols 298 can be used to change parameters associated to a prefix, such as the 299 preferred lifetime. 301 5.1.2 Other failure modes 303 There are other failures modes where there are some parts of the 304 Internet reachable using one prefix and other parts of the Internet 305 are reachable using a different prefix. For instance, in the next 306 figure, when a failure occurs in the link between ISPA and the rest 307 of the Internet, host X should use address B:X to reach host C:Y, but 308 host X should use address A:X to reach D:Z. 310 Z 311 ( Site Z) 312 | 313 ( ISPD ) 314 | 315 /-- ( ISPA ) ---( ) 316 X (site X) ( IPv6 ) ---( ISPC )---(site Y) Y 317 \-- ( ISPB ) ---( ) 319 In this scenario, ISPD has its own prefix Prefix D and it obtains 320 Internet connectivity through ISPA. So, in this case, deprecating 321 the prefix associated with ISPA would preclude communication with 322 Site Z. 324 In this scenario a mechanism like NAROS [6] can be used. In this 325 mechanism, a server acquires the reachability information available 326 in the inter-domain routing system using BGP. This means that there 327 are BGP sessions established between each site exit router and the 328 border router of the correspondent ISP, through which the site exit 329 router obtains interdomain routing information. The server 330 establishes IBGP sessions with each site exit router, so it discovers 331 which destinations are reachable through each ISP. In the case there 332 is no outage, all destinations are reachable through all the ISPs, so 333 no information has to be propagated to the hosts. In case of a 334 failure, a set of destinations will become unreachable through one (o 335 more) ISP(s). In this case, the server has to inform the hosts about 336 which prefix to use for the different destinations. The host can 337 store this information in the policy table defined in RFC 3484. This 338 policy table allows the host to prefer a certain source address for a 339 given set of destinations. 341 The missing part is a mechanism to convey the information from the 342 server to the host. A possible option is to define a new DHCP option 343 to transmit policy table information. The precise format of the DHCP 344 option is out of the scope of this document. 346 In the example above, the mechanism would work as follows. Before 347 the outage, the site exit router of site X are obtaining a default 348 route from both ISPs. The hosts have the default policy table 349 configured. 351 When an outage occurs in the link between ISPA and the Internet, ISPB 352 still announces a default route, while ISPA will announce only a 353 route to prefix A and to prefix D (and not a default route). This 354 information is transmitted to the server that will craft the new 355 policy table. Because of the longest prefix match rule of source 356 address selection algorithm defined in RFC 3484, A:X will be the 357 preferred source address when sending packet to destinations 358 containing prefix A. So, the new policy table must inform that for 359 destinations containing prefix D the prefix A should be used in the 360 source address. Additionally the policy table must reflect that for 361 the rest of destinations prefix B should be preferred. This is 362 achieved by adding the following entries to the policy table: 364 Prefix Precedence Label 365 Prefix A 10 11 366 Prefix D 10 11 367 ::/0 10 12 368 Prefix B 10 12 370 Because both entries have the same Label, Rule 6 (Prefer matching 371 label) of the source address selection algorithm will select the 372 source address containing prefix A when sending packets to 373 destinations containing Prefix D. Also because rule 6, for the rest 374 of the destinations, the source address containing Prefix B will be 375 preferred. The new policy table is transmitted to the hosts using 376 the new DHCP option. 378 5.2 Reactive mechanisms 380 In this approach, the host will try with different source addresses 381 until the communication is established. After the communication is 382 established, the information about which source address to use for 383 different destinations is stored in a Source Address Cache. Each 384 entry of the cache contains for a Destination Address, information 385 about the corresponding Source Address and a lifetime. 387 The source address cache entry creation process is the following: 389 When the host receives a packet containing a Source Address SA and a 390 Destination Address DA, the Exit Path Cache is searched for an entry 391 that contains SA Destination Address field. 393 - If such entry is found, the Source Address is verified. 395 -- If the Source Address contains DA, then the lifetime of the entry 396 is extended. 398 -- If the Source Address is other than DA, then the cache entry is 399 updated and DA is stored in the Source Address field. The lifetime 400 of the entry is extended. (would this break some apps?) 402 - If the entry is not found, the entry is created, with SA as the 403 Destination Address and DA as the Source Address. The entry is 404 blocked from changes for a certain period to avoid that multiple 405 answers produce suboptimal behavior. 407 There are different retrial strategies that can be used in this 408 approach. 410 The first option is to simply let the upper layers to handle 411 retrials. In this case, the IP layer only has to make sure that a 412 different source address is used in each retrial as long as there is 413 not a preferred source address in the source address cache. So, in 414 this approach, when the IP layer receives a packet, it searches the 415 Source Address Cache for a preferred source address associated to the 416 selected destination. If no entry exists for that destination 417 address, one of the available source addresses is selected randomly. 418 If reply packets arrive, an entry will be created in the Source 419 Address Cache for that destination address. If no reply packets 420 arrive, no entry will be created, so when the upper layer protocol 421 resends the packet, a new source address will be used. 423 The second option would be that the IP layer handles retrials. In 424 this case, the IP layer stores the packet and retries until a Source 425 Address Cache entry is created for that destination. This approach 426 imposes that the IP layer has to store the packets sent to 427 destinations that still don't have a Source Address Cache entry 428 created. It should be noted that the IP layer is incapable of 429 recognizing if incoming packets are actually replies to the packets 430 sent, since the IP layer knowledge is limited to the source and 431 destination address pair. This means that the retransmission service 432 provided by the IP layer won't be reliable. Additionally, this 433 approach requires the definition of timeouts after which the IP layer 434 will resend the packets. Since the IP layer has no information about 435 the round trip times or reply time of the involved applications, the 436 selection of this timer will be arbitrary. 438 The third option would be to try with all possible source address 439 simultaneously. In this approach, when the IP layer receives a 440 packet from the upper layer, it searches the Source Address Cache for 441 the destination of the packet. If an entry is found for that 442 destination, the source address contained in the Source Address Cache 443 is used. If no entry is found for that destination, the IP layer 444 sends as many packets as different source address are available, each 445 one with a different address. In this case, the IP layer doesn't 446 need to store any packets and it doesn't rely retransmission by upper 447 layer protocols. What is more, this approach would provide the 448 selection of the best path, since the destination address of the 449 first reply packet could be used as source address, selecting the 450 fastest path available. The main drawback of this approach is the 451 additional load imposed by duplicated packets. 453 6. Future steps 455 This memo presents multiple possible approaches to select address for 456 initiating new communications after an outage in multihomed 457 environments. At this point, the goal of the memo is to foster 458 discussion about the benefits and drawbacks of each approach, so that 459 eventually a set of mechanisms can be selected. 461 7. Acknowledgments 463 This memo contains parts of a previous work entitled "Host-Centric 464 IPv6 Multihoming" that benefited from comments from Alberto Garcia 465 Martinez, Cedric de Launois, Brian Carpenter, Dave Crocker, Xiaowei 466 Yang and Erik Nordmark. 468 8 References 470 [1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 471 IP Version 6 (IPv6)", RFC 2461, December 1998. 473 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 474 Autoconfiguration", RFC 2462, December 1998. 476 [3] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 477 2000. 479 [4] Abley, J., Black, B. and V. Gill, "Goals for IPv6 480 Site-Multihoming Architectures", RFC 3582, August 2003. 482 [5] Draves, R., "Default Address Selection for Internet Protocol 483 version 6 (IPv6)", RFC 3484, February 2003. 485 [6] de Launois, C. and O. Bonaventure, "NAROS : Host-Centric IPv6 486 Multihoming with Traffic Engineering", ID 487 draft-de-launois-multi6-naros-00.txt, May 2003. 489 [7] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 490 Configuration Protocol (DHCP) version 6", RFC 3633, December 491 2003. 493 Authors' Addresses 495 Christian Huitema 496 Microsoft Corporation 497 One Microsoft Way 498 Redmond, WA 98052-6399 499 USA 501 Phone: 502 EMail: huitema@microsoft.com 503 URI: 505 Richard Draves 506 Microsoft Corporation 507 One Microsoft Way 508 Redmond, WA 98052-6399 509 USA 511 Phone: 512 EMail: richdr@microsoft.com 513 URI: 515 Marcelo Bagnulo 516 Universidad Carlos III de Madrid 517 Av. Universidad 30 518 Leganes, Madrid 28911 519 SPAIN 521 Phone: 34 91 6249500 522 EMail: marcelo@it.uc3m.es 523 URI: http://www.it.uc3m.es 525 Intellectual Property Statement 527 The IETF takes no position regarding the validity or scope of any 528 Intellectual Property Rights or other rights that might be claimed to 529 pertain to the implementation or use of the technology described in 530 this document or the extent to which any license under such rights 531 might or might not be available; nor does it represent that it has 532 made any independent effort to identify any such rights. Information 533 on the procedures with respect to rights in RFC documents can be 534 found in BCP 78 and BCP 79. 536 Copies of IPR disclosures made to the IETF Secretariat and any 537 assurances of licenses to be made available, or the result of an 538 attempt made to obtain a general license or permission for the use of 539 such proprietary rights by implementers or users of this 540 specification can be obtained from the IETF on-line IPR repository at 541 http://www.ietf.org/ipr. 543 The IETF invites any interested party to bring to its attention any 544 copyrights, patents or patent applications, or other proprietary 545 rights that may cover technology that may be required to implement 546 this standard. Please address the information to the IETF at 547 ietf-ipr@ietf.org. 549 Disclaimer of Validity 551 This document and the information contained herein are provided on an 552 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 553 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 554 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 555 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 556 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 557 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 559 Copyright Statement 561 Copyright (C) The Internet Society (2004). This document is subject 562 to the rights, licenses and restrictions contained in BCP 78, and 563 except as set forth therein, the authors retain all their rights. 565 Acknowledgment 567 Funding for the RFC Editor function is currently provided by the 568 Internet Society.