idnits 2.17.1 draft-bourdais-dhcp-cluster-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 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 594. ** 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. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 105 has weird spacing: '...ed upon the u...' == Line 158 has weird spacing: '...to many attac...' == Line 221 has weird spacing: '...ational examp...' == Line 455 has weird spacing: '...cording to a ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 17, 2005) is 6766 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (ref. '3') (Obsoleted by RFC 8415) -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Bourdais 3 Internet-Draft France Telecom R&D 4 Expires: April 20, 2006 October 17, 2005 6 DHCP cluster 7 draft-bourdais-dhcp-cluster-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 20, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document describes a design of DHCP server that relies upon the 41 use of an external storage entity. Such solution provides an 42 alternative solution to the DHCP failover protocol for the deployment 43 of multiple DHCP servers. 45 Conventions used in this document 47 RFC2119 [1] provides the interpretations for the key words "MUST", 48 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 49 "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Overview of the DHCP Cluster . . . . . . . . . . . . . . . . . 5 57 5. Considerations on DHCP cluster designs . . . . . . . . . . . . 6 58 5.1 DHCP load balancing . . . . . . . . . . . . . . . . . . . 6 59 5.2 Hardware load-balancing . . . . . . . . . . . . . . . . . 8 60 5.3 Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 6. Client-cluster interaction . . . . . . . . . . . . . . . . . . 10 62 6.1 Cluster with DHC load balancing . . . . . . . . . . . . . 10 63 6.2 Cluster with load-balancing appliance . . . . . . . . . . 11 64 6.3 Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 68 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 70 Intellectual Property and Copyright Statements . . . . . . . . 14 72 1. Introduction 74 The document is possibly applicable to both DHCP for IPv4 and IPv6 75 networks. The main comparison is held with DHCPv4 since there are 76 numerous known implementations and operational applications, and also 77 because RFC3315 [3] is less specific about the information storage 78 environment than RFC2131 [2] is. 80 DHCP is widely used in networks of multiple sizes and eases the pain 81 of terminal configuration. Within operator network environments, the 82 main DHCP deployments are cable-modem, mobile and wireless networks. 84 In xDSL networks, operators traditionally prefer PPP to DHCP because 85 of its capability to provide user authentication and accounting. 86 However, the introduction of new IP services, such as video and 87 video-conferencing, and the capabilities of the related terminals, 88 push DHCP as a key protocol to configure terminals in a plug and play 89 fashion. 91 In this context, the operators have to define an operational 92 framework in which the DHCP server takes a critical role. Compared 93 to traditional corporate networks, the level of requirements is 94 higher in terms of availability, scalability and security 95 capabilities. Other requirements are also of primary importance, 96 such as the capability of the DHCP server to interface smoothly with 97 external entities which would require DHCP service-related 98 information. 100 From the operator's viewpoint, IPv4 addresses are precious resources, 101 and the DHCP server is therefore expected to assist him for 102 controlling and monitoring their allocation. 104 This document describes a DHCP server that complies with the design 105 goals described in section 1.6 of RFC2131, based upon the use of an 106 external centralized storage entity. Its design is a potential 107 alternative to DHCP Failover protocol for the deployment of multiple 108 DHCP servers. 110 2. Terminology 112 This document uses the same terminology as of RFC2131, with the 113 following additional terms : 115 o DHCP repository : An host working as a centralized storage entity 116 for one or several DHCP nodes. It contains the binding 117 information related to DHCP clients. 119 o DHCP node : A host processing DHCP messages which is connected to 120 an externalized repository. 121 o DHCP cluster : A platform gathering one or several DHCP nodes 122 connected to a centralized DHCP repository. 124 3. Requirements 126 The aim is to meet the following list of requirements : 128 o Compliancy with RFC2131. 129 o Flexibility regarding the address allocation mechanisms : static 130 and dynamic allocation mechanisms, possible interrogation of a 131 third party entity during the DHCP message processing. 132 o Reliability : reduce downtime while ensuring high service 133 availability even when provisioning, troubleshooting and 134 maintenance operations occur. 135 o OSS integration : the DHCP server should easily interface with 136 external entities, in order to fulfill operational tasks such as 137 automated provisioning, monitoring and reporting of the usage of 138 IP addresses. The information stored by the DHCP server should be 139 available for external entities within the OSS. 140 o Scalability : the DHCP server should provide an efficient and 141 scalable service, in front of multiple entities embedding DHCP 142 agent relays. 143 o Serving multiple purposes : the same DHCP server should allow the 144 allocation of IP addresses for a wide range of applications, e.g. 145 TV over xDSL, IP telephony or video-conferencing. It involves a 146 necessary support for the provisioning of different kinds of 147 terminals, either mono or multi-service capable, and a support for 148 interpretation of DHCP message content, e.g. MAC address, GIADDR, 149 options 60/77/82 and others. 150 o Inter-working within a DHCP environment : the DHCP server should 151 deal with the implementation and behavior of DHCP relay agents. 152 For example, the lack of an encoding formalism in RFC3046 [4] for 153 the circuit-id sub-option, which is a fundamental information for 154 an operator, results in various encoding schemes by the network 155 entities that are entitled to add information in the DHCP option 156 #82. 157 o Security : without DHCP authentication as described in RFC3118 158 [5], a DHCP server remains subject to many attacks, such as DoS, 159 lease attacks to exhaust free leases, spoofing of any DHCP message 160 sent by terminals, etc. However, the DHCP server should provide 161 some mechanism to report and detect potential attacks or 162 malfunctions, and to filter DHCP messages based on part of the 163 content, e.g. GIADDR or MAC address prefix. 165 4. Overview of the DHCP Cluster 167 The cluster design follows RFC2131 as the main reference. It takes a 168 specific direction on the information storage aspect compared to many 169 existing DHCP server implementations. 171 Section 4 of RFC2131 assumes that the DHCP server offers a local 172 storage capability. The storage environment is also mentioned in 173 sections 2.1 and 3. 175 RFC3315 does not discuss the way the storage of DHCP-related 176 information should be implemented. The term 'database' is not even 177 mentioned. 179 The choice of performing DHCP message processing and storage on the 180 same entity is an interpretation of RFC2131. This choice has many 181 advantages, including to avoid creating data persistence issues and 182 to optimize the speed of the DHCP service. However, there is a main 183 drawback when several DHCP servers are deployed and used on the same 184 network. The RFC2131 mentions these situations, but does not specify 185 how DHCP servers would cooperate to ensure the consistency of 186 information between multiple DHCP services. 188 The DHCP cluster is a DHCP server implementation that relies upon an 189 externalized storage database which is shared locally among several 190 DHCP nodes. These nodes process DHCP messages and have limited 191 configuration information. They do not deal with lease consistency, 192 which is a task achieved through the externalized database. 194 The resulting platform may be described as a group of one or several 195 DHCP message processing nodes, and a centralized repository to which 196 the nodes are connected. This DHCP repository stores both 197 configuration and lease information related to the DHCP service. 199 Physically, each DHCP node is embedded in a host, while the database 200 may consist in several hosts, e.g. with replication or database grid. 202 ----------- ----------- ----------- 203 | DHCP node | | DHCP node | | DHCP node | 204 -----+----- -----+----- -----+----- 205 | | | 206 +-------------------+-------------------+ 207 | 208 ----+----- 209 |Repository| 210 ---------- 212 Figure 1 - Description of a DHCP cluster 213 There is no need for an inter-node communication protocol such as the 214 DHCP failover protocol [7] with this design. 216 The DHC load balancing algorithm [6] may be used as solution to share 217 the processing task on the DHCP nodes. 219 The inter-working of DHCP nodes with an externalized entity naturally 220 slows down the service by comparison with a server embedding its 221 database. However, there are many operational examples of such DHCP 222 servers interfaced with external databases or LDAP repositories 223 showing that a tradeoff between service performance and functional 224 requirements may be acceptable for an operator. 226 5. Considerations on DHCP cluster designs 228 Given the roles of DHCP nodes and database entities, there are 229 several possible designs. The following ones offer different options 230 in terms of entities' deployment and software/hardware load sharing. 232 These designs may have potential impacts on the functional behavior 233 of the DHCP nodes which are part of the cluster. 235 For all designs, the repository represents a point of failure. Its 236 redundancy may be enforced either through grid or replication 237 mechanisms. 239 5.1 DHCP load balancing 241 This design consists in using DHC load balancing algorithm, as 242 defined in RFC3074, on the DHCP nodes connected to the centralized 243 repository. 245 All nodes are interconnected to the rest of the relay agents, and 246 must maintain load balancing parameters that are required for 247 efficient DHCP service cooperation. 249 From the viewpoint of the DHCP clients and relay agents, the DHCP 250 nodes of the cluster are concurrent. The relay agents must point 251 towards all the DHCP nodes that are part of the cluster. Thus, all 252 incoming DHCP messages are unicast to all DHCP nodes. 254 | | | 255 | | | 256 -----+----- -----+----- -----+----- 257 | DHCP node | | DHCP node | | DHCP node | 258 | HBA-1 | | HBA-2 | | HBA-3 | 259 -----+----- -----+----- -----+----- 260 | | | 261 +-------------------+-------------------+ 262 | 263 ----+----- 264 |Repository| 265 ---------- 267 Figure 2 - DHCP cluster with DHCP Load balancing 269 Operations, e.g. add or remove a new node, requires to modify the 270 configuration on the relay agents with an updated list of active DHCP 271 nodes accordingly. Also, the load balancing Hashing Bucket 272 Assignments (HBA) of each node must be updated when an operation or a 273 failure occurs to maintain a complementary behavior, and optionnaly 274 use the Delayed Service behavior described in RFC3074. 276 Upon receipt of an unicast request forwarded by a relay agent, each 277 DHCP node follows the following behavior : 279 1. Check the integrity of the DHCP message 280 2. Apply the load balancing algorithm to find out the node that has 281 will be responsible for processing this request 282 3. Process the DHCP message 284 The DHCP message processing step may include the enforcement of 285 access control and policy rules based on the content of each DHCP 286 message. 288 A rule is defined as a regular expression which contains one or 289 several elements among the information available in a DHCP message. 290 Upon verification of this rule, the DHCP message is dropped or not. 291 As an example, a rule may be defined based upon the MAC address 292 prefix to filter the terminal from a given vendor. 294 Then, the DHCP nodes interrogates the repository in order to find an 295 adequate configuration for the terminal. This question may be simple 296 or complex, e.g. involving one or several parameters among all the 297 information available in a DHCP message. 299 During a connection attempt between a node and the repository, there 300 are three cases: 302 o No connection : if the DHCP node cannot reach the main repository 303 within a given timeframe, it must address the same interrogation 304 to a backup repository, if any. 305 o Failure : the repository does not find any configuration matching 306 the interrogation. It must reply to the DHCP node so that the 307 latter with either drop the request or send a NACK message. 308 o Success : The repository finds a matching configuration including 309 a valid lease. It must mark the selected lease and reply to the 310 DHCP node with the information related to the binding. 312 Upon receipt of the response of the repository, the DHCP node 313 constructs the DHCP message and sends it to the requesting device 314 that will be assigned an IP address. 316 5.2 Hardware load-balancing 318 The introduction of a specific hardware appliance to ensure load 319 balancing, e.g. Layer-four switch, is an alternative to the use of 320 the DHCP load balancing algorithm to distribute the load among the 321 DHCP nodes. 323 Since this choice is technology specific, it is considered here only 324 because of its functional impact on the cluster behavior. 326 In such design, the DHCP nodes and repository are interconnected to 327 the rest of the network through one or several hardware load 328 balancing appliances. 330 The DHCP platform may be hidden from the terminals and relay agents, 331 by making them point to these appliances. The advantage is that any 332 operation on a node, e.g. insertion/removal of a DHCP node, is 333 transparent for the clients and relay agents. 335 The appliance should be configured to forward only packets using DHCP 336 destination and source ports. 338 Since the node may be completely stateless, it may process DHCP 339 messages at any step of a DHCP transaction. 341 In order to orientate the DHCP clients and relay agents towards the 342 appropriate appliance, the field 'server identifier' provisioned by 343 the DHCP nodes constructing the DHCP messages MUST contain the IP 344 address of the appliance's WAN interface. 346 | 347 -----------------------+----------------------- 348 | Load balancing appliance(s) | 349 ---+-------------------+-------------------+--- 350 | | | 351 | | | 352 -----+----- -----+----- -----+----- 353 | DHCP node | | DHCP node | | DHCP node | 354 -----+----- -----+----- -----+----- 355 | | | 356 +-------------------+-------------------+ 357 | 358 ----+----- 359 |Repository| 360 ---------- 362 Figure 3 - DHCP cluster with load balancing appliance 364 The advantage of such a design is that each DHCP entity is 365 specialized in performing a specific task : 367 o The DHCP nodes are dedicated to DHCP message processing and 368 process all the received DHCP messages 369 o The DHCP repository is the centralized source for provisioning IP 370 addresses and managing lease information 372 5.3 Anycast 374 The Anycast design of the DHCP cluster is an approach where DHCP 375 nodes may be located in different areas while maintaining a 376 relationship with a common DHCP repository. The connection between 377 DHCP nodes and the repository may not be persistent. 379 The DHC load balancing algorithm is not applicable. 381 All DHCP nodes are configured with an anycast address. The access 382 network router forwards the DHCP messages towards the nearest DHCP 383 node from an IP routing standpoint. 385 | | | 386 | | | 387 -----+----- -----+----- -----+----- 388 | DHCP node | | DHCP node | | DHCP node | 389 -----+----- -----+----- -----+----- 390 | | | 391 +-------------------+-------------------+ 392 | 393 ----+----- 394 |Repository| 395 ---------- 397 Figure 4 - DHCP cluster with anycast 399 6. Client-cluster interaction 401 This section describes the protocol exchanges between clients and 402 cluster for the three designs, considering the DHCP message 403 chronology (DISCOVER, OFFER, REQUEST, ACK). 405 Section 3 of RFC2131 is the reference for the description of the 406 exchanges. 408 6.1 Cluster with DHC load balancing 410 1. The client broadcasts a DHCP DISCOVER message on its local 411 physical subnet. The DHCP DISCOVER message MAY include options 412 that suggest values for the network address and lease duration. 413 A DHCP relay agent may pass the message on to all DHCP nodes, 414 assuming the clients and nodes are not on the same physical 415 subnet. It may insert additional information through the relay 416 agent information option following RFC3046. 417 2. Each node should use the load balancing algorithm to find out if 418 it must process this request. When processing the request, the 419 node must analyze the DHCP message by comparing its content to 420 configured rules. If this comparison match a rule, the node 421 interrogates the repository to find a binding that corresponds to 422 the DHCP DISCOVER along with parameters among those present in 423 the DHCP message. 424 3. The repository receives the question and checks if there is a 425 binding corresponding to the request. If not, the request should 426 be discarded. Otherwise, the repository marks the corresponding 427 IP address as "reserved" and sends the information towards the 428 DHCP node that initiated the question. This mark may involve 429 several parameters including the reserved IP address, the MAC 430 address, the client-identifier and other information available in 431 the DHCP request. If several nodes send the same question, the 432 repository should answer to all the nodes with the exact same 433 response. 434 4. Based on the repository response, a node responds with a DHCP 435 OFFER message that includes the IP address in the 'yiaddr' field, 436 its own address in the 'server identifier' option, and other 437 configuration parameters in DHCP options. When allocating a new 438 IP address, nodes should check that the offered network address 439 is not already in use, e.g. with an ICMP Echo Request. Such 440 feature MAY be disabled. 442 6.2 Cluster with load-balancing appliance 444 1. The client broadcasts a DHCP DISCOVER message on its local 445 physical subnet. The DHCP DISCOVER message MAY include options 446 that suggest values for the network address and lease duration. 447 A DHCP relay agent may pass the message on to the cluster by 448 targeting the IP address of the load-balancing appliance in case 449 it is not on the same physical subnet. It may insert additional 450 information through the relay agent information option following 451 RFC3046. 452 2. The appliance receives packets identified as DHCP messages 453 through port identification or a complete packet analysis. Any 454 packet that are not with DHCP ports should be filtered by the 455 appliance. According to a configured distribution algorithm, 456 the appliance forwards the message to one of the DHCP nodes of 457 the cluster. 458 3. The selected DHCP node receives the request and must analyze the 459 DHCP message by comparing its content to configured rules. If 460 this comparison match a rule, the node interrogates the 461 repository to find a binding that corresponds to the DHCP 462 DISCOVER along with the parameters sent by the client and other 463 potential parameters inserted by a relay agent. 464 4. The repository checks if there is a binding corresponding to the 465 request. If not, the request should be discarded. Otherwise, 466 the repository marks the corresponding IP address as "reserved" 467 and sends the information to the DHCP node which initiated the 468 question. This mark may involve several parameters including the 469 reserved IP address, the MAC address, the client-identifier and 470 other information available in the DHCP request. If the terminal 471 resends the request and that the same question is sent by another 472 node, the repository must answer with the same response. 473 5. Based on the repository response, the node responds with a DHCP 474 OFFER message that includes the IP address in the 'yiaddr' field, 475 the IP address of the load-balancing appliance in the 'server 476 identifier' option, and other configuration parameters in DHCP 477 options. The response does not need to transit through the 478 appliance. When allocating a new IP address, nodes should check 479 that the offered network address is not already in use, e.g. with 480 an ICMP Echo Request. Such feature MAY be disabled. 482 6.3 Anycast 484 1. The client broadcasts a DHCP DISCOVER message on its local 485 physical subnet. The DHCP DISCOVER message MAY include options 486 that suggest values for the network address and lease duration. 487 A DHCP relay agent may pass the message on to the cluster by 488 targeting the Anycast IP address of the DHCP cluster, in case a 489 DHCP node is not on the same physical subnet. It may insert 490 additional information through the relay agent information option 491 following RFC3046. 492 2. According to anycast routing, one DHCP node receives the request, 493 and must analyze the DHCP message by comparing its content to 494 configured rules. If this comparison match a rule, the node 495 interrogates the repository to find a binding that corresponds to 496 the DHCP DISCOVER message along with parameters sent by the 497 client and other potential parameters inserted by a relay agent. 498 3. The repository receives the question and check if there is a 499 binding corresponding to the request. If not, the request should 500 be discarded. Otherwise, the repository marks the corresponding 501 IP address as reserved and sends the information to the DHCP node 502 that initiated the question. This mark may involve several 503 parameters including the reserved IP address, the MAC address, 504 the client-identifier and other information available in the DHCP 505 request. If the terminal resends the request and that the same 506 question is sent by another node, the repository should answer 507 with the same response. 508 4. Based on the repository's response, the node responds with a 509 DHCPOFFER message that includes the IP address in the 'yiaddr' 510 field, the anycast IP address of the DHCP cluster in the 'server 511 identifier' option, and other configuration parameters in DHCP 512 options. When allocating a new IP address, nodes should check 513 that the offered network address is not already in use, e.g. with 514 an ICMP Echo Request. Such feature MAY be disabled. 516 7. Security Considerations 518 This document does not raise any further issue as far as the security 519 related to the use of DHCP is concerned. 521 The use of rules based on DHCP information as access control and/or 522 policies to enforce IP address allocation corresponds to a classic 523 feature. 525 RFC3118 is the reference to achieve authentication of DHCP messages, 526 and could be implemented with the DHCP cluster in the same way it 527 could be implemented with any implementation following RFC2131 528 guideline. 530 8. IANA considerations 532 None. 534 9. Acknowledgments 536 Many thanks to Frederic Le Garrec, Christian Jacquenet and Hidega 537 Tiku for their inputs. 539 10. Normative References 541 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 542 Levels", BCP 14, RFC 2119, March 1997. 544 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 545 March 1997. 547 [3] Droms, R., "Dynamic Host Configuration Protocol for IPv6", 548 RFC 3315, July 2003. 550 [4] Patrick, M., "DHCP relay agent Information Option", RFC 3046, 551 January 2001. 553 [5] Droms, R., "Authentication for DHCP Messages", RFC 3118, 554 June 2001. 556 [6] Volz, B., "DHC Load Balancing Algorithm", RFC 3074, 557 February 2001. 559 [7] Droms, R., "DHCP Failover Protocol", draft version 10 failover, 560 February 2002. 562 Author's Address 564 Francois Bourdais 565 France Telecom R&D 566 905 rue albert einstein 567 Sophia Antipolis 06921 568 France 570 Email: francois.bourdais@francetelecom.com 572 Intellectual Property Statement 574 The IETF takes no position regarding the validity or scope of any 575 Intellectual Property Rights or other rights that might be claimed to 576 pertain to the implementation or use of the technology described in 577 this document or the extent to which any license under such rights 578 might or might not be available; nor does it represent that it has 579 made any independent effort to identify any such rights. Information 580 on the procedures with respect to rights in RFC documents can be 581 found in BCP 78 and BCP 79. 583 Copies of IPR disclosures made to the IETF Secretariat and any 584 assurances of licenses to be made available, or the result of an 585 attempt made to obtain a general license or permission for the use of 586 such proprietary rights by implementers or users of this 587 specification can be obtained from the IETF on-line IPR repository at 588 http://www.ietf.org/ipr. 590 The IETF invites any interested party to bring to its attention any 591 copyrights, patents or patent applications, or other proprietary 592 rights that may cover technology that may be required to implement 593 this standard. Please address the information to the IETF at 594 ietf-ipr@ietf.org. 596 Disclaimer of Validity 598 This document and the information contained herein are provided on an 599 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 600 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 601 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 602 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 603 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 604 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 606 Copyright Statement 608 Copyright (C) The Internet Society (2005). This document is subject 609 to the rights, licenses and restrictions contained in BCP 78, and 610 except as set forth therein, the authors retain all their rights. 612 Acknowledgment 614 Funding for the RFC Editor function is currently provided by the 615 Internet Society.