idnits 2.17.1 draft-riegel-tuexen-mobile-sctp-09.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 590. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 5, 2007) is 6016 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: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC2026' is defined on line 499, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2002 (Obsoleted by RFC 3220) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Riegel 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Experimental M. Tuexen, Ed. 5 Expires: May 8, 2008 Muenster Univ. of Applied Sciences 6 November 5, 2007 8 Mobile SCTP 9 draft-riegel-tuexen-mobile-sctp-09.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 21 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 May 8, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Transport layer mobility management is presented in addition to 43 Mobile IP for providing seamless mobility in the Internet. By use of 44 SCTP (Stream Control Transmission Protocol) and some of its currently 45 proposed extensions a seamless handover can be fully accomplished in 46 the mobile client without any provisions in the network, only 47 assisted by functions embedded in Mobile SCTP enabled servers. 49 Client mobility management based on Mobile SCTP seems not to require 50 any new protocol development. It is a particular application of SCTP 51 eventually solving the requirements of transport layer mobility in 52 the Internet. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Intention . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Network layer mobility . . . . . . . . . . . . . . . . . . 3 59 1.3. Transport layer mobility . . . . . . . . . . . . . . . . . 3 60 1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 3 61 2. Transport protocols . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Transport layer functions . . . . . . . . . . . . . . . . 3 63 2.2. Transport protocols supporting multihoming . . . . . . . . 4 64 2.3. Mobility enabled transport protocols . . . . . . . . . . . 4 65 3. Transport layer mobility . . . . . . . . . . . . . . . . . . . 5 66 3.1. Transport layer mobility by example . . . . . . . . . . . 5 67 3.1.1. Initial connection to the Internet . . . . . . . . . . 5 68 3.1.2. Soft handover . . . . . . . . . . . . . . . . . . . . 6 69 3.1.3. Tear down of the initial link . . . . . . . . . . . . 6 70 3.1.4. The procedure continues... . . . . . . . . . . . . . . 6 71 4. Mobile SCTP, the mobility enabled profile of SCTP . . . . . . 7 72 4.1. Support of multihoming . . . . . . . . . . . . . . . . . . 7 73 4.2. Dynamic addition and deletion of IP-addresses . . . . . . 7 74 5. Requirements for Mobile SCTP enabled hosts . . . . . . . . . . 8 75 5.1. Requirements for mobile clients . . . . . . . . . . . . . 8 76 5.2. Requirements for Mobile SCTP enabled servers . . . . . . . 9 77 6. Further considerations . . . . . . . . . . . . . . . . . . . . 9 78 6.1. Crossing different network technologies . . . . . . . . . 9 79 6.2. Combination of link layer mobility and transport layer 80 mobility . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 6.3. Time multiplexed network interfaces . . . . . . . . . . . 10 82 6.4. Mobile servers . . . . . . . . . . . . . . . . . . . . . . 10 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 89 Intellectual Property and Copyright Statements . . . . . . . . . . 13 91 1. Introduction 93 1.1. Intention 95 It is the intention of this I-D to continue a discussion to explore 96 the nits and nuts of transport layer mobility management. Please 97 send comments to the mailing list 'mobile@sctp.de'. 98 To subscribe to this mailing list, please send a mail to 99 mobile-request@sctp.de. 101 1.2. Network layer mobility 103 Traditionally mobility in the Internet is accomplished by making sure 104 the moving host is reachable by its originally assigned IP address 105 even when the address leaves the network area the address belongs to. 106 To keep reachability by an address outside its assigned area the 107 protocol Mobile IP [RFC2002] can be used installing an agent in the 108 home area taking care of all packets sent to a mobile host currently 109 outside its native network area. The home agent knows about the 110 foreign location of the mobile host and forwards all packets 111 addressed to it to an agent in the foreign location which finally 112 delivers the packets to the mobile host. Home agent and foreign 113 agent are connected by a tunnel making the mobility enabled network 114 layer 'circuit switched'. 116 1.3. Transport layer mobility 118 Transport layer mobility management keeps the circuitless nature of 119 the network layer of the Internet untouched and implements the whole 120 functionality for providing mobility to hosts in the transport layer 121 entities at both ends of the network. The transport layer of the 122 Internet is the first layer going up the networking stack which 123 provides end-to-end control. 125 1.4. Acknowledgements 127 The authors would like to thank M. Bokaemper, A. Chana, C. Ross, H. 128 J. Schwarzbauer and many others for their valuable comments and 129 suggestions. 131 2. Transport protocols 133 2.1. Transport layer functions 135 A client host accesses a particular service over the Internet by 136 establishing a transport layer connection to a server host providing 137 such service. This connection is typically made reliable by an 138 appropriate transport control protocol and carries the application 139 protocol elements and all the user data of a particular service 140 between the hosts over the Internet. Applications needing a reliable 141 transport may use the Transmission Control Protocol (TCP) which 142 provides a reliable, duplicate free and in-sequence delivery of user 143 data. 145 The transport layer makes use of transport layer addresses. For the 146 Transmission Control Protocol this is a pair consisting on an IP- 147 address and a port number. A TCP connection is established between 148 two TCP endpoints, each of the TCP endpoints being identified by one 149 transport layer address of TCP. 151 It is important that the two TCP endpoints of a TCP connection can 152 not change during the lifetime of a TCP connection. 154 When a host changes its IP address, for example by attaching to a new 155 network, existing TCP connections can not use this new address 156 because the TCP endpoint can not be changed. This is one of the 157 reasons why today Mobile IP is used to provide the mobile host with a 158 constant IP address which is used for communication with the peer. 160 2.2. Transport protocols supporting multihoming 162 A host is called multihomed if it has multiple network layer 163 addresses. In case of IP networks this means that the host has 164 multiple IP-addresses. This does not necessarily mean that the host 165 has also multiple link layer interfaces. Multiple IP addresses can 166 be configured on a single link layer interface. 168 A transport protocol supports multihoming if the endpoints can have 169 more than one transport layer addresses. These transport layer 170 addresses are considered as logically different paths of the peer 171 towards the endpoint with the multiple transport addresses. 173 2.3. Mobility enabled transport protocols 175 Transport layer protocols allowing the modification of the endpoints 176 during the lifetime of a connection are called mobility enabled 177 transport protocols. A mobility enabled transport protocol allows 178 for the change of the IP address of the network layer while keeping 179 the end-to-end connection intact. If the transport protocol supports 180 multihoming and the host can attach to multiple networks the 181 transport protocol can make use of the simultaneous connection. 183 3. Transport layer mobility 185 The mobility enabled transport layer shields the application not only 186 from the actual network beneath and provides virtual circuits end to 187 end through the Internet but also hides the change of underlying 188 network addresses. Most application protocols, except those using IP 189 addresses in messages of their own will continue to work when being 190 ported to a mobility enabled transport layer. 192 Since the mobility is now handled by the endpoints which reside in 193 the hosts and not in the network the transport layer mobility 194 connection harmonises fully with the nature of the Internet. 196 3.1. Transport layer mobility by example 198 The following picture illustrates the concept of transport layer 199 mobility. This example is based on a mobility enabled transport 200 protocol supporting multihoming. Also only a mobile client 201 connecting to a server is considered 203 Loc A 204 ######### [2.0.0.2] ******* 205 # #I- - - - -I ******** ** 206 # #I A ** ** ** ** 207 ######### / \___* * ******* * 208 | | * ********* * *** +------+ 209 Moving from A to B **** ** [8.0.0.4]| | 210 \| |/ * Internet *** *----------| | 211 Loc B\ / * * ** * [8.0.0.5]+------+ 212 ######### * ** * ** * * Server 213 # #I * ******** * * 214 # #I- - - - -I * ** * ** 215 ######### [4.0.0.3]A * ******* 216 Mobile Client / \____* * 217 ******** 219 Figure 1 221 3.1.1. Initial connection to the Internet 223 A mobile client connects to the Internet by some wireless technology 224 and gets assigned an IP address from the local address space at 225 location A [e.g. 2.0.0.2]. This can be accomplished by any of the 226 techniques currently known for dynamic address assignment, like PPP 227 or DHCP. 229 The mobile client being now reachable over the Internet establishes a 230 transport layer connection to a server anywhere 'in' the Internet 232 [e.g. 8.0.0.4] and starts using the provided service. 234 3.1.2. Soft handover 236 The mobile client moves from location A towards location B and gets 237 knowledge of reaching the coverage of another network by information 238 from the physical layer of its NIC. In addition to the already 239 existing link the mobile client establishes a link to the network at 240 location B and gets assigned an IP address of the network at location 241 B on its second network interface. Thus the mobile client becomes 242 multi-homed and is now reachable by two different networks. 244 The mobile client tells the corresponding server using the 245 established transport layer connection that it is now reachable by a 246 second IP address. Technically speaking, it adds the newly assigned 247 IP address to the association identifying the connection to the 248 server. To enable easy distinction of the two links at the mobile 249 client several IP addresses should be assigned to the network 250 interface of the server. This allows to represent different links by 251 different entries in the routing table of the mobile client. 253 On reaching location B the mobile client may leave the coverage of 254 the access point at location A and may loose the link for its first 255 IP address. The data stream between server and mobile client gets 256 interrupted and the reliability behavior of the transport protocol 257 ensures that all data is sent over the second link in the case of 258 permanent failure of the first link. 260 If the mobile client has access to information about the strength of 261 the wireless signal the handover to the second link will be initiated 262 before severe packet loss occurs, making the handover more soft. 264 3.1.3. Tear down of the initial link 266 When the mobile client has proved by information from the physical 267 layer that the failure of the first link is permanent, it will inform 268 its peer that it is now no longer reachable by the first IP address 269 and removes this IP address from the association. 271 3.1.4. The procedure continues... 273 When the mobile client moves on, it may reach the coverage of another 274 wireless network. It will repeat the procedure described above 275 gaining seamless mobility while keeping running applications working. 277 4. Mobile SCTP, the mobility enabled profile of SCTP 279 The Stream Control Transmission Protocol (SCTP) as currently being 280 defined in [RFC4960] with the extension described in [RFC5061] is an 281 example of a mobility enabled transport protocol supporting 282 multihoming. 284 A further extension to the SCTP protocol also enables the partial 285 reliable transport of data extending the applicability of transport 286 layer mobility management from applications based on a reliable 287 transport protocol (TCP, for example) to applications currently 288 realized on an unreliable transport protocol (UDP, for example). See 289 [RFC3758] for more details. 291 4.1. Support of multihoming 293 An SCTP transport address is a pair of an IP-address and a port 294 number as in the case of TCP. But an SCTP endpoint can be identified 295 by a sequence of SCTP transport addresses all sharing the same port 296 number. 298 An association is a connection between two SCTP endpoints. 300 An SCTP endpoint can use multiple IP-addresses for an association. 301 These are exchanged during the initiation of the association. The 302 multiple addresses of the peer are considered as different paths 303 towards that peer. 305 This means that a server must use multiple IP-addresses to provide 306 the mobile client with multiple paths. These will be used while 307 moving between locations. 309 It should be mentioned that this path-concept is used only for 310 redundancy, not for load sharing. Therefore one path is used for 311 normal transmission of user data. It is called the primary path. 313 For a more detailed description see [RFC4960], [RFC3257], and 314 [RFC3286]. 316 4.2. Dynamic addition and deletion of IP-addresses 318 The SCTP extension described in [RFC5061] makes SCTP a mobilty 319 enabled transport protocol. This means that it allows an SCTP 320 endpoint to change its IP-addresses. 322 Furthermore it is possible for an SCTP endpoint to signal to its peer 323 which IP-address it should use as the primary path. This is very 324 useful in case of multiple Internet acesses with different 325 parameters. 327 5. Requirements for Mobile SCTP enabled hosts 329 The only general requirement is that the transport protocol must be 330 SCTP with the extensions described in [RFC5061]. 332 5.1. Requirements for mobile clients 334 To motivate the requirements for the mobile client one has to 335 consider the situation where the client has connections to multiple 336 access point. The following figure shows this scenario with two 337 access points. 339 ******* 340 +--I ******** ** 341 [2.0.0.2]| A ** ** ** ** 342 | / \___* * ******* * 343 ######### | * ********* * *** +------+ 344 # #I------+ **** ** [8.0.0.4]| | 345 # #I------+ * Internet *** *----------| | 346 ######### | * * ** * [8.0.0.5]+------+ 347 [4.0.0.3]| * ** * ** * * 348 +--I * ******** * * 349 A * ** * ** 350 / \____* ******* 351 Mobile Client ********* Server 353 Figure 2 355 During the time where the mobile client is reachable via two 356 different access networks it has to make sure that it uses both 357 links. Thus, for example, the forwarding of the mobile client has to 358 be set up in a way that the traffic towards 8.0.0.4 uses the upper 359 link (interface 2.0.0.2) and the traffic towards 8.0.0.5 uses the 360 lower link (interface 4.0.0.3). 362 The mobile client also knows the quality of the two links and can 363 make sure that it uses the better one whenever appropriate. Using 364 the ability to request the server to modify its primary path it is 365 also possible that the mobile client makes sure that the traffic from 366 the server towards the mobile client uses the better link. 368 It should be mentioned that this link handover has to be done 369 carefully to avoid oscillation and frequent switching. 371 Summarizing this, the mobile client must use an implementation of 372 SCTP with the extension [RFC5061]. Furthermore the forwarding table 373 of the mobile client has to be modified according the connectivity 374 state. 376 5.2. Requirements for Mobile SCTP enabled servers 378 The server must use multiple IP-addresses and a SCTP implementation 379 supporting the extension [RFC5061]. 381 6. Further considerations 383 6.1. Crossing different network technologies 385 Keeping seamless connectivity while switching between different 386 network technologies, e.g. using wireless LAN in a hot-spot area and 387 automaticaly switching over to a second or third generation public 388 mobile network when leaving the hot-spot area, can be accomplished by 389 Mobile SCTP without any additional functionality. 391 It doesn't matter for Mobile SCTP whether the network interfaces 392 belong to the same technology or different technologies as long as it 393 is possible to establish a connection to the Internet via the 394 interfaces. Depending on the technology of the network interfaces 395 different strategies may be applied for selecting the link to be 396 used. 398 6.2. Combination of link layer mobility and transport layer mobility 400 Some radio technologies like IEEE802.11 wireless LAN provide mobility 401 management functionalities in the link layer. Link layer handover is 402 mostly restricted to micro mobility but can be advantageously 403 combined with transport layer mobility management reducing the 404 processing requirements at the server side for handling all the 405 handovers. 407 If Mobile SCTP is used in a IEEE802.11 environment a mobile client 408 has o make four decisions: 409 o Depending of physical parameters the mobile client has to decide 410 when to associate with a base station. For making this decision 411 it can take, for example, the signal strength into account. 412 o After establishing the wireless link layer a method for IP- 413 configuration has to be used. But it makes only sense to do this, 414 if the wireless link is stable and there is a chance to really use 415 it. 416 o After the configuration of the new link is completed a decision 417 has to be made when this new path is announced to the peer using 418 the ADDIP mechanisms. 420 o The last decision is when to ask the peer to use the new pathas 421 the primary path. 423 The first decision clearly depends on link layer parameters. All 424 four decisions have in common that they must be done in a way which 425 avoids oscillations. For doing this link layer information has to be 426 used in all four decisions. For example, you want to do the last 427 decision only when you are quite sure that the new path will have the 428 best transmission characteristics for some time. 430 6.3. Time multiplexed network interfaces 432 All descriptions in this I-D assume mobile clients with at least two 433 network interfaces. Some kind of wireless technology might allow to 434 use one network interface card to establish several network 435 connections quasi in parallel in a time multiplexed manner. This 436 might lead to some considerable cost benefits for mobile clients, but 437 does not change the basic procedures of transport layer mobility 438 management. 440 6.4. Mobile servers 442 The description up to now mostly focuses on mobile clients using 443 services from fixed servers. Sometimes the other way round might be 444 necessary: addressing mobile hosts from fixed hosts. In this case 445 there are two additional problems to solve: 446 o Due to location dependent dynamic assignment of IP addresses to 447 mobile hosts there must be a way to address the mobile host 448 independently from their dynamically assigned addresses. 449 o Mobile SCTP does not handle the simultaneous handover of both SCTP 450 endpoints. If both endpoints perform a handover at the same time, 451 the SCTP association will be lost. Please note, that Mobile SCTP 452 can handle handovers of both SCTP endpoints if they happen 453 sequentially. 455 The method to solve the above problems must take into account the 456 frequency of handovers. The second problem might not occur that 457 often compared to the first one. 459 One possible solution of the first problem can be based on special 460 adoptions to the DNS to take care of the IP-address changes. Such a 461 solution will not solve the second problem. 463 Another possible technique to handle the mobility of hosts can be 464 based on the RSerPool protocol suite. This allows to access a 465 server, or a pool element in RSerPool terminology, by using a pool 466 handle. The RSerPool protocol suite can be implemented on small 467 devices like cellular phones as required in [RFC3237]. 469 Mobile host would be addressed by a pool handle and in case a mobile 470 host changes its IP-addresses it would reregister with the new IP- 471 Addresses itself. This information would be distributed 472 automatically between all RSerPool name servers. It should be noted, 473 that this solution might not be appropriate for the Internet but for 474 a smaller IP-based network correlating to an RSerPool operational 475 scope. 477 In case of the simultaneous handover the RSerPool session would stay 478 intact even if the SCTP association breaks. If the mobile node have 479 implemented a way of resynchronizing their states the communication 480 between them might only be affected slightly. RSerPool provides a 481 COOKIE mechanism which can be used in some scenarios for 482 resynchronizing the states. 484 7. Security Considerations 486 If IPSec is used to secure the SCTP communication new security 487 associations have to be established during the addition/deletion of 488 IP addresses. This introduces an additional delay. If TLS [RFC3436] 489 is used this can be avoided. 491 8. IANA Considerations 493 There are no actions needed. 495 9. References 497 9.1. Normative References 499 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 500 3", BCP 9, RFC 2026, October 1996. 502 9.2. Informative References 504 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 505 Conrad, "Stream Control Transmission Protocol (SCTP) 506 Partial Reliability Extension", RFC 3758, May 2004. 508 [RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, 509 October 1996. 511 [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., 512 Loughney, J., and M. Stillman, "Requirements for Reliable 513 Server Pooling", RFC 3237, January 2002. 515 [RFC3257] Coene, L., "Stream Control Transmission Protocol 516 Applicability Statement", RFC 3257, April 2002. 518 [RFC3286] Ong, L. and J. Yoakum, "An Introduction to the Stream 519 Control Transmission Protocol (SCTP)", RFC 3286, May 2002. 521 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 522 Layer Security over Stream Control Transmission Protocol", 523 RFC 3436, December 2002. 525 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 526 RFC 4960, September 2007. 528 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 529 Kozuka, "Stream Control Transmission Protocol (SCTP) 530 Dynamic Address Reconfiguration", RFC 5061, 531 September 2007. 533 Authors' Addresses 535 Maximilian Riegel 536 Nokia Siemens Networks 537 St.-Martin Strasse 76 538 81541 Munich 539 Germany 541 Phone: +49 89 636 75194 542 Email: maximilian.riegel@nsn.com 544 Michael Tuexen (editor) 545 Muenster Univ. of Applied Sciences 546 Stegerwaldstr. 39 547 48565 Steinfurt 548 Germany 550 Email: tuexen@fh-muenster.de 552 Full Copyright Statement 554 Copyright (C) The IETF Trust (2007). 556 This document is subject to the rights, licenses and restrictions 557 contained in BCP 78, and except as set forth therein, the authors 558 retain all their rights. 560 This document and the information contained herein are provided on an 561 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 562 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 563 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 564 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 565 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 566 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 568 Intellectual Property 570 The IETF takes no position regarding the validity or scope of any 571 Intellectual Property Rights or other rights that might be claimed to 572 pertain to the implementation or use of the technology described in 573 this document or the extent to which any license under such rights 574 might or might not be available; nor does it represent that it has 575 made any independent effort to identify any such rights. Information 576 on the procedures with respect to rights in RFC documents can be 577 found in BCP 78 and BCP 79. 579 Copies of IPR disclosures made to the IETF Secretariat and any 580 assurances of licenses to be made available, or the result of an 581 attempt made to obtain a general license or permission for the use of 582 such proprietary rights by implementers or users of this 583 specification can be obtained from the IETF on-line IPR repository at 584 http://www.ietf.org/ipr. 586 The IETF invites any interested party to bring to its attention any 587 copyrights, patents or patent applications, or other proprietary 588 rights that may cover technology that may be required to implement 589 this standard. Please address the information to the IETF at 590 ietf-ipr@ietf.org. 592 Acknowledgment 594 Funding for the RFC Editor function is provided by the IETF 595 Administrative Support Activity (IASA).