idnits 2.17.1 draft-ietf-netlmm-nohost-ps-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 511. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 11) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.0 Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5.0 Security Considerations' ) ** 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 an Authors' Addresses Section. ** There are 288 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 16 has weird spacing: '... By submi...' == Line 30 has weird spacing: '... The list...' == Line 33 has weird spacing: '... The list ...' == Line 63 has weird spacing: '... recent devel...' == Line 68 has weird spacing: '... of globa...' == (7 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 471 looks like a reference -- Missing reference section? '2' on line 473 looks like a reference -- Missing reference section? '3' on line 475 looks like a reference -- Missing reference section? '4' on line 477 looks like a reference -- Missing reference section? '5' on line 479 looks like a reference -- Missing reference section? '6' on line 481 looks like a reference -- Missing reference section? '7' on line 484 looks like a reference -- Missing reference section? '8' on line 486 looks like a reference -- Missing reference section? '9' on line 488 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 J. Kempf,Editor 3 Internet Draft K. Leung 4 Document: draft-ietf-netlmm-nohost-ps-01.txt P. Roberts 5 K. Nishida 6 G. Giaretta 7 M. Liebsch 9 Expires: October, 2006 April, 2006 11 Problem Statement for IP Local Mobility 12 (draft-ietf-netlmm-nohost-ps-01.txt) 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware have been 18 or will be disclosed, and any of which he or she becomes aware will be 19 disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering Task Force 22 (IETF), its areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months and 26 may be updated, replaced, or obsoleted by other documents at any time. It is 27 inappropriate to use Internet-Drafts as reference material or to cite them 28 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 Abstract 38 In this document, the well-known problem of localized mobility management 39 for IP link handover is given a fresh look. After a short discussion of the 40 problem and a couple of scenarios, the principal shortcomings of existing 41 solutions are discussed. 43 Table of Contents 45 1.0 Introduction.....................................................2 46 2.0 The Local Mobility Problem.......................................4 47 3.0 Scenarios for Localized Mobility Management......................6 48 4.0 Problems with Existing Solutions.................................7 49 5.0 Security Considerations..........................................9 50 6.0 Author Information...............................................9 51 7.0 Informative References..........................................10 52 8.0 IPR Statements..................................................10 53 9.0 Disclaimer of Validity..........................................11 54 10.0 Copyright Notice................................................11 56 1.0 Introduction 58 Localized mobility management has been the topic of much work in the IETF 59 for some time, and it may seem as if little remains to be said on the topic. 60 The experimental protocols developed from previous work, namely FMIPv6 [1] 61 and HMIPv6[2], involve host-based solutions that mimic to a greater or 62 lesser extent the approach taken by Mobile IPv6 [3] for global mobility 63 management. However, recent developments in the IETF and the WLAN 64 infrastructure market suggest that it may be time to take a fresh look at 65 localized mobility management. Firstly, new IETF work on global mobility 66 management protocols that are not Mobile IPv6, such as HIP [4] and Mobike 67 [5], suggests that future wireless IP nodes may support a more diverse set 68 of global mobility protocols. Secondly, the success in the WLAN 69 infrastructure market of WLAN switches, which perform localized mobility 70 management without any host stack involvement, suggests a possible design 71 paradigm that could be used to accommodate other global mobility management 72 options on the mobile node while reducing host stack software complexity and 73 expanding the range of mobile nodes that could be accommodated. 75 This document briefly describes the local mobility problem and a few 76 scenarios where localized mobility management would be desirable. Then, it 77 describes the two most serious problems with existing protocols: the 78 requirement for host stack support, and the complex security interactions 79 required between the mobile node and the access network. More detailed 80 requirements and gap analysis for existing protocols can be found in [6]. 82 1.1 Terminology 84 Mobility terminology in this draft follows that in RFC 3753 [7], with the 85 addition of some new and revised terminology given here: 87 IP Link 88 A set of routers, mobile nodes, and wireless access points that share 89 link broadcast capability or its functional equivalent. This definition 90 covers one or multiple access points under one or several access 91 routers. In the past, such a set has been called a subnet, but this 92 term is not strictly correct for IPv6, since multiple subnet prefixes 93 can be assigned to an IP link in IPv6. 95 Access Network (revised) 96 An Access Network consists of following three components: wireless or 97 other access points, access routers, access network gateways which form 98 the boundary to other networks and may shield other networks from the 99 specialized routing protocols (if any) run in the Access Network; and 100 (optionally) other internal access network routers which may also be 101 needed in some cases to achieve a specialized routing protocol. 103 Local Mobility (revised) 104 Local Mobility is mobility over a restricted area of the network 105 topology. Note that, although the area of network topology over which 106 the mobile node moves may be restricted, the actual geographic area 107 could be quite large, depending on the mapping between the network 108 topology and the wireless coverage area. 110 Localized Mobility Management 111 Localized Mobility Management is a generic term for protocols dealing 112 with IP mobility management confined within the access network. 113 Localized mobility management signaling is not routed outside the 114 access network, although a handover may trigger Global Mobility 115 Management signaling. Localized mobility management protocols exploit 116 the locality of movement by confining movement related changes to the 117 access network. 119 Localized Mobility Management Protocol 120 A protocol that supports localized mobility management. 122 Global Mobility Protocol 123 A Global Mobility Protocol is a mobility protocol used by the mobile 124 node to change the global, end-to-end routing of packets when movement 125 causes a topology change and thus invalidates a global unicast address 126 on the local IP link currently in active use by the mobile node. The 127 Global Mobility Protocol may also allow the mobile node to maintain a 128 mapping between a permanent address and a temporary address on the 129 local network for rendezvous with nodes that want to initiate a 130 connection. Typically, this protocol will be Mobile IPv6 [1] but it 131 could also be HIP [4] or Mobike [5] (Note: although Mobike is not 132 considered a mobility management protocol in general, for purposes of 133 this document, it will be so considered because it manages the address 134 map and routing between a fixed VPN endpoint address and a changing 135 local address). 137 Global Mobility Anchor Point 138 A node in the network where the mobile node maintains a permanent 139 address and a mapping between the permanent address and the local 140 temporary address where the mobile node happens to be currently 141 located. The Global Mobility Anchor Point may be used for purposes of 142 rendezvous and possibly traffic forwarding. For Mobile IPv6 [1], this 143 is the home agent. For HIP [4], this may be the rendezvous server. For 144 Mobike [5], this is the VPN tunnel gateway in the home network. 146 Intra-Link Mobility 147 Intra-Link Mobility is mobility between wireless access points within 148 an IP Link. Typically, this kind of mobility only involves Layer 2 149 mechanisms, so Intra-Link Mobility is often called Layer 2 mobility. No 150 IP link configuration is required upon movement since the link does not 151 change, but some IP signaling may be required for the mobile node to 152 confirm whether or not the change of wireless access point also 153 resulted in a change of IP link. If the IP link consists of a single 154 access point/router combination, then this type of mobility is 155 typically absent. See Figure 1. 157 2.0 The Local Mobility Problem 159 The local mobility problem is restricted to providing IP mobility management 160 for mobile nodes within an access network. The access network aggregation 161 routers function as an access network gateway, although in this case, there 162 is no specialized routing protocol and the routers function as a standard IP 163 routed network. This is illustrated in Figure 1, where the aggregation 164 routers are designated as "AggR". Transitions between service providers in 165 separate autonomous systems or across broader topological "boundaries" 166 within the same service provider are excluded. 168 Figure 1 depicts the scope of local mobility in comparison to global 169 mobility. The Aggregation Routers AggR A1 and B1 are gateways to the access 170 network. The Access Routers AR A1 and A2 are in Access Network A, B1 is in 171 Access Network B. Note that it is possible to have additional aggregation 172 routers between AggR A1 and AggR B1 and the access routers if the access 173 network is large. Access Points AP A1 through A3 are in Access Network A, B1 174 and B2 are in Access Network B. Other Aggregation Routers, Access Routers, 175 and Access Points are also possible. The figure implies a star topology for 176 the access network deployment, and the star topology is the primary one of 177 interest since it is quite common, but the problems discussed here are 178 equally relevant to ring or mesh topologies in which access routers are 179 directly connected through some part of the network. 181 Access Network A Access Network B 183 +-------+ +-------+ 184 |AggR A1| (other AggRs) |AggR B1| (other AggRs) 185 +-------+ +-------+ 186 @ @ @ 187 @ @ @ 188 @ @ @ 189 @ @ @ 190 @ @ @ 191 @ @ @ 192 +-----+ +-----+ +-----+ 193 |AR A1| |AR A2|(other ARs) |AR B1| (other ARs) 194 +-----+ +-----+ +-----+ 195 * * * 196 * * * * * 197 * * * * * 198 * * * * * 199 * * * * * 200 * * * (other APs) * * (other APs) 201 /\ /\ /\ /\ /\ 202 /AP\ /AP\ /AP\ /AP\ /AP\ 203 / A1 \ / A2 \ / A3 \ / B1 \ / B2 \ 204 ------ ------ ------ ------ ------ 206 +--+ +--+ +--+ +--+ 207 |MN|----->|MN|----->|MN|-------->|MN| 208 +--+ +--+ +--+ +--+ 209 Intra-link Local Global 210 Mobility Mobility Mobility 212 Figure 1. Scope of Local and Global Mobility Management 214 As shown in the figure, a global mobility protocol is necessary when a 215 mobile node (MN) moves between two access networks. Exactly what the scope 216 of the access networks is depends on deployment considerations. Mobility 217 between two access points under the same access router constitutes Intra- 218 link mobility, and is typically handled by Layer 2 mobility protocols (if 219 there is only one access point/cell per access router, then intra-link 220 mobility may be lacking). Between these two lies local mobility. Local 221 mobility occurs when a mobile node moves between two access points connected 222 to two different access routers. 224 Global mobility protocols allow a mobile node to maintain reachability when 225 a change between access routers occurs, by updating the address mapping 226 between the permanent address and temporary local address at the global 227 mobility anchor point, or even end to end by changing the temporary local 228 address directly at the node with which the mobile node is corresponding. A 229 global mobility management protocol can therefore be used between access 230 routers for handling local mobility. However, there are three well-known 231 problems involved in using a global mobility protocols for every transition 232 between access routers. Briefly, they are: 234 1) Update latency. If the global mobility anchor point and/or 235 correspondent node (for route optimized traffic) is at some distance 236 from the mobile node's access network, the global mobility update may 237 require a considerable amount of time, during which time packets 238 continue to be routed to the old temporary local address and are 239 essentially dropped. 240 2) Signaling overhead. The amount of signaling required when a mobile 241 node moves from one IP link to another can be quite extensive, 242 including all the signaling required to configure an IP address on the 243 new link and global mobility protocol signaling back into the network 244 for changing the permanent to temporary local address mapping. The 245 signaling volume may negatively impact wireless bandwidth usage and 246 real time service performance. 247 3) Location privacy. The change in temporary local address as the mobile 248 node moves exposes the mobile node's topological location to 249 correspondents and potentially to eavesdroppers. An attacker that can 250 assemble a mapping between subnet prefixes in the mobile node's access 251 network and geographical locations can determine exactly where the 252 mobile node is located. This can expose the mobile node's user to 253 threats on their location privacy. 255 These problems suggest that a protocol to localize the management of 256 topologically small movements is preferable to using a global mobility 257 management protocol on each IP link move. In addition to these problems, 258 localized mobility management can provide a measure of local control, so 259 mobility management can be tuned for specialized local conditions. Note also 260 that if localized mobility management is provided, it is not strictly 261 required for a mobile node to support a global mobility management protocol 262 since movement within a restricted IP access network can still be 263 accommodated. Without such support, however, a mobile node experiences a 264 disruption in its traffic when it moves beyond the border of the localized 265 mobility management domain. 267 3.0 Scenarios for Localized Mobility Management 269 There are a variety of scenarios in which localized mobility management is 270 attractive. 272 3.1 Large Campus with Diverse Physical Interconnectivity 274 One scenario where localized mobility management would be attractive is for 275 a campus wireless LAN deployment in which parts of the campus are connected 276 by links that are other than 802.3 or in which it is not possible to cover 277 the campus by one VLAN. In this case, the campus is divided into separate IP 278 links each served by one or more access routers. This kind of deployment is 279 served today by wireless LAN switches that co-ordinate IP mobility between 280 them, effectively providing localized mobility management at the link layer. 281 Since the protocols are proprietary and not interoperable, any deployments 282 that require IP mobility necessarily require switches from the same vendor. 284 3.2 Advanced Cellular Network 286 Next generation cellular protocols such as 802.16e [8] and Super 3G/3.9G [9] 287 have the potential to run IP deeper into the access network than the current 288 3G cellular protocols, similar to today's WLAN networks. This means that the 289 access network can become a routed IP network. Interoperable localized 290 mobility management can unify local mobility across a diverse set of 291 wireless protocols all served by IP, including advanced cellular, WLAN, and 292 personal area wireless technologies such as UWB and Bluetooth. Localized 293 mobility management at the IP layer does not replace Layer 2 mobility (where 294 available) but rather complements it. A standardized, interoperable 295 localized mobility management protocol for IP can remove the dependence on 296 IP layer localized mobility protocols that are specialized to specific link 297 technologies or proprietary, which is the situation with today's 3G 298 protocols. The expected benefit is a reduction in maintenance cost and 299 deployment complexity. See [6] for a more detailed discussion of the 300 requirements for localized mobility management. 302 3.3 Picocellular Network with Small But Node-Dense IP Links 304 Future radio link protocols at very high frequencies may be constrained to 305 very short, line of sight operation. Even some existing protocols, such as 306 UWB and Bluetooth, are designed for low power, short range operation. For 307 such protocols, extremely small picocells become more practical. Although 308 picocells do not necessarily imply "pico IP links", wireless sensors and 309 other advanced applications may end up making such picocellular type 310 networks node-dense, requiring subnets that cover small geographical areas, 311 such as a single room. The ability to aggregate many subnets under a 312 localized mobility management scheme can help reduce the amount of IP 313 signaling required on IP link movement. 315 4.0 Problems with Existing Solutions 317 Existing solutions for localized mobility management fall into three 318 classes: 320 1) Interoperable IP level protocols that require changes to the mobile node's 321 IP stack and handle localized mobility management as a service provided to 322 the mobile node by the access network, 323 2) Link specific or proprietary protocols that handle localized mobility for 324 any mobile node but only for a specific type of link layer, namely 802.11 325 running on an 802.3 wired network backhaul. 326 3) Use of a standard IGP such as OSPF or IS-IS to distribute host routes, and 327 updating the host routes when the mobile node moves. 329 For Solution 1, the following are specific problems: 331 1) The host stack software requirement limits broad usage even if the 332 modifications are small. The success of WLAN switches indicates that 333 network operators and users prefer no host stack software modifications. 334 This preference is likely to be independent of the lack of widespread 335 Mobile IPv4 deployment, since it is much easier to deploy and use the 336 network. 337 2) Future mobile nodes may choose other global mobility management 338 protocols, such as HIP or Mobike. The existing localized mobility 339 management solutions all depend on Mobile IP or derivatives. 340 3) Existing localized mobility management solutions do not support both IPv4 341 and IPv6. 343 4) Security for the existing localized mobility management solutions 344 requires complex security associations with network elements for no 345 improvement in security over what is available if localized mobility 346 management is not used. In addition to the additional signaling required 347 to set up these security associations, provisioning a mobile node with 348 credentials for roaming to all the access networks where the mobile node 349 might end up may prove difficult, acting as a barrier to deployment. 351 Solution 2 has the following problems: 353 1) Existing solutions only support WLAN networks with Ethernet backhaul and 354 therefore are not available for advanced cellular networks or 355 picocellular protocols, or other types of wired backhaul. 356 2) Each WLAN switch vendor has its own proprietary protocol that does not 357 interoperate with other vendor's equipment. 358 3) Because the solutions are based on layer 2 routing, they may not scale up 359 to a metropolitan area, or local province. 361 Solution 3 has the following problems: 363 1) Each router in the localized mobility management domain is required to 364 maintain a host route table and to search the host route table for 365 routing each packet, limiting the memory and processing power 366 scalability. 367 2) After handover, until host routes propagate back along the current path 368 of traffic to the localized mobility management domain border, traffic 369 packets for the mobile node are sent to the old router, causing the 370 packets to drop. Since IGPs typically propagate routing updates through 371 flooding, the delay in host route propagation also limits the topological 372 span of the localized mobility management domain. 373 3) Rapid movement by the mobile node faster than the rate at which flooding 374 can propagate host routes could lead to a cascading series of host route 375 messages that never stabilize. 377 Having an interoperable, standardized localized mobility management protocol 378 that is scalable to topologically large networks, but requires no host stack 379 involvement for localized mobility management is a highly desirable 380 solution. Mobility routing anchor points within the backbone network 381 maintain a collection of routes for individual mobile nodes. The routes 382 point to the access routers on which mobile nodes currently are located. 383 Packets for the mobile node are routed to and from the mobile node through 384 the mobility anchor point. When a mobile node moves from one access router 385 to another, the access routers send a route update to the mobility anchor 386 point. While some mobile node involvement is necessary and expected for 387 generic mobility functions such as movement detection and to inform the 388 access router about mobile node movement, no specific mobile node to network 389 protocol will be required for localized mobility management itself. 391 The advantages that this solution has over the Solutions 1 through 3 above 392 are as follows: 394 1) Compared with Solution 1, a network-based solution requires no localized 395 mobility management support on the mobile node and is independent of 396 global mobility management protocol, so it can be used with any or none 397 of the existing global mobility management protocols. The result is a 398 more modular mobility management architecture that better accommodates 399 changing technology and market requirements. 400 2) Compared with Solution 2, an IP level network-based localized mobility 401 management solution works for link protocols other than Ethernet, and for 402 wide area networks. 403 3) Compared with Solution 3, the framework described above for network-based 404 localized mobility management only requires the involvement of the access 405 routers and the mobility anchor. All other routers within the localized 406 mobility management domain do not need to handle host routes, making the 407 architecture more scalable. In addition, because updating the routes 408 requires communication between only two routers, propagation of routes on 409 handover is likely to be much faster. 411 5.0 Security Considerations 413 Localized mobility management has certain security considerations, one of 414 which - need for access network to mobile node security - was touched on in 415 this document. Existing localized mobility management solutions increase the 416 need for mobile node to access network signaling and provisioning of the 417 mobile node with credentials without increasing the security beyond what is 418 available if no localized mobility management solution is used. A more 419 complete discussion of the security requirements for localized mobility 420 management can be found in [6]. 422 6.0 Author Information 424 James Kempf 425 DoCoMo USA Labs 426 181 Metro Drive, Suite 300 427 San Jose, CA 95110 428 USA 429 Phone: +1 408 451 4711 430 Email: kempf@docomolabs-usa.com 432 Kent Leung 433 Cisco Systems, Inc. 434 170 West Tasman Drive 435 San Jose, CA 95134 436 USA 437 EMail: kleung@cisco.com 439 Phil Roberts 440 Motorola Labs 441 Schaumberg, IL 442 USA 443 Email: phil.roberts@motorola.com 445 Katsutoshi Nishida 446 NTT DoCoMo Inc. 447 3-5 Hikarino-oka, Yokosuka-shi 448 Kanagawa, 449 Japan 450 Phone: +81 46 840 3545 451 Email: nishidak@nttdocomo.co.jp 453 Gerardo Giaretta 454 Telecom Italia Lab 455 via G. Reiss Romoli, 274 456 10148 Torino 457 Italy 458 Phone: +39 011 2286904 459 Email: gerardo.giaretta@tilab.com 461 Marco Liebsch 462 NEC Network Laboratories 463 Kurfuersten-Anlage 36 464 69115 Heidelberg 465 Germany 466 Phone: +49 6221-90511-46 467 Email: marco.liebsch@ccrle.nec.de 469 7.0 Informative References 471 [1] Koodli, R., editor, "Fast Handovers for Mobile IPv6," RFC 4068, July, 472 2005. 473 [2] Soliman, H., editor, "Hierarchical Mobile IPv6 Mobility Management," 474 RFC 4140, August, 2005. 475 [3] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in IPv6," 476 RFC 3775. 477 [4] Moskowitz, R., Nikander, P., Jokela, P., and Henderson, T., "Host 478 Identity Protocol", Internet Draft, work in progress. 479 [5] Kivinen, T., and Tschopfening, H., "Design of the MOBIKE Protocol", 480 Internet Draft, work in progress. 481 [6] Kempf, J., Leung, K., Roberts, P., Giaretta, G., Liebsch, M., and 482 Nishita, K.., "Requirements and Gap Analysis for Localized Mobility 483 Management", Internet Draft, work in progress. 484 [7] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC 3753, 485 June, 2004. 486 [8] IEEE, "Air Interface for Mobile Broadband Wireless Access Systems", 487 802.16e, 2005. 488 [9] 3GPP, "3GPP System Architecture Evolution: Report on Technical Options 489 and Conclusions", TR 23.882, 2005, http://www.3gpp.org/ftp/Specs/html- 490 info/23882.htm. 492 8.0 IPR Statements 494 The IETF takes no position regarding the validity or scope of any 495 Intellectual Property Rights or other rights that might be claimed to 496 pertain to the implementation or use of the technology described in this 497 document or the extent to which any license under such rights might or might 498 not be available; nor does it represent that it has made any independent 499 effort to identify any such rights. Information on the procedures with 500 respect to rights in RFC documents can be found in BCP 78 and BCP 79. 502 Copies of IPR disclosures made to the IETF Secretariat and any assurances of 503 licenses to be made available, or the result of an attempt made to obtain a 504 general license or permission for the use of such proprietary rights by 505 implementers or users of this specification can be obtained from the IETF 506 on-line IPR repository at http://www.ietf.org/ipr. 508 The IETF invites any interested party to bring to its attention any 509 copyrights, patents or patent applications, or other proprietary rights that 510 may cover technology that may be required to implement this standard. 511 Please address the information to the IETF at ietf-ipr@ietf.org. 513 9.0 Disclaimer of Validity 515 This document and the information contained herein are provided on an "AS 516 IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS 517 SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 518 TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 519 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 520 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 521 FOR A PARTICULAR PURPOSE. 523 10.0 Copyright Notice 525 Copyright (C) The Internet Society (2006). This document is subject to the 526 rights, licenses and restrictions contained in BCP 78, and except as set 527 forth therein, the authors retain all their rights.