idnits 2.17.1 draft-ietf-netlmm-nohost-ps-02.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 560. ** 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 23 has weird spacing: '... months and ...' == Line 28 has weird spacing: '... The list ...' == Line 71 has weird spacing: '...equired by M...' == Line 72 has weird spacing: '... recent devel...' == Line 78 has weird spacing: '... it is p...' == (22 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) -- Obsolete informational reference (is this intentional?): RFC 4068 (ref. '1') (Obsoleted by RFC 5268) -- Obsolete informational reference (is this intentional?): RFC 4140 (ref. '2') (Obsoleted by RFC 5380) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '3') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4423 (ref. '4') (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 3220 (ref. '13') (Obsoleted by RFC 3344) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Kempf, Editor 3 Document: draft-ietf-netlmm-nohost-ps-02.txt 5 Expires: December, 2006 June, 2006 7 Problem Statement for Network-based IP Local Mobility 8 (draft-ietf-netlmm-nohost-ps-02.txt) 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 Localized mobility management is a well understood concept in the 37 IETF with a number of solutions already available. This document 38 looks at the principal shortcomings of the existing solutions, all 39 of which involve the host in mobility management, and makes a case 40 for network-based local mobility management. 42 Contributors 44 Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and 45 Marco Liebsch all contributed major effort to this document. Their 46 names are not included in the authors' section due to the RFC 47 Editor's limit of 5 names. 49 Table of Contents 51 1.0 Introduction.............................................2 52 2.0 The Local Mobility Problem...............................4 53 3.0 Scenarios for Localized Mobility Management..............6 54 4.0 Problems with Existing Solutions.........................7 55 5.0 IANA Considerations......................................9 56 6.0 Security Considerations..................................9 57 7.0 Acknowledgements........................................10 58 8.0 Author Information......................................10 59 9.0 Informative References...................................9 60 10.0 IPR Statements..........................................11 61 11.0 Disclaimer of Validity..................................11 62 12.0 Copyright Notice........................................11 64 1.0 Introduction 66 Localized mobility management has been the topic of much work in 67 the IETF. The experimental protocols developed from previous work, 68 namely FMIPv6 [1] 69 and HMIPv6 [2], involve host-based solutions that require host 70 involvement at the IP layer similar to or in addition to that 71 required by Mobile IPv6 [3] for global mobility management. 72 However, recent developments in the IETF and the WLAN 73 infrastructure market suggest that it may be time to take a fresh 74 look at localized mobility management. Firstly, new IETF work on 75 global mobility management protocols that are not Mobile IPv6, such 76 as HIP [4] and Mobike [5], suggests that future wireless IP nodes 77 may support a more diverse set of global mobility protocols. While 78 it is possible that existing localized mobility management 79 protocols could be used with HIP and Mobike, it would require 80 additional effort to implement and deploy these localized mobility 81 management protocols in an non-Mobile IPv6 mobile environment. 82 Secondly, the success in the WLAN infrastructure market of WLAN 83 switches, which perform localized management without any host stack 84 involvement, suggests a possible paradigm that could be used to 85 accommodate other global mobility options on the mobile node while 86 reducing host stack software complexity expanding the range of 87 mobile nodes that could be accommodated. 89 This document briefly describes the general local mobility problem 90 and scenarios where localized mobility management would be 91 desirable. Then problems with existing or proposed IETF localized 92 mobility management protocols are briefly discussed. The network- 93 based mobility management architecture and a short description of 94 how it solves these problems is presented. A more detailed 95 discussion of goals for a network-based, localized mobility 96 management protocol and gap analysis for existing protocols can be 97 found in [6]. Note that IPv6 and wireless links are considered to 98 be the primary focal points for a network-based localized mobility 99 management, so the language in this document reflects that focus. 100 However, the conclusions of this document apply equally to IPv4 and 101 wired links where nodes are disconnecting and reconnecting. 103 1.1 Terminology 104 Mobility terminology in this draft follows that in RFC 3753 105 [7], with the addition of some new and revised terminology 106 given here: 108 IP Link 110 A set of routers, mobile nodes, and wireless access points 111 that share link broadcast capability or its functional 112 equivalent. This definition covers one or multiple access 113 points under one or several access routers. In the past, 114 such a set has been called a subnet, but this term is not 115 strictly correct for IPv6, since multiple subnet prefixes 116 can be assigned to an IP link in IPv6. 118 Local Mobility (revised) 119 Local Mobility is mobility over an access network. Note 120 that, although the area of network topology over which the 121 mobile node moves may be restricted, the actual geographic 122 area could be quite large, depending on the mapping between 123 the network topology and the wireless coverage area. 125 Localized Mobility Management 127 Localized Mobility Management is a generic term for any IP 128 protocol that maintains the IP connectivity and reachability 129 of a mobile node when it moves, and whose signalling is 130 confined to an access network. 132 Localized Mobility Management Protocol 134 A protocol that supports localized mobility management. 136 Global Mobility Management Protocol 138 A Global Mobility Management Protocol is a mobility protocol 139 used by the mobile node to change the global, end-to-end 140 routing of packets when movement causes a topology change 141 and thus invalidates a global unicast address on the local 142 IP link currently in active use by the mobile node. This 143 protocol could be Mobile IP [1][13] but it could also be HIP 144 [4] or Mobike [5] (Note: although Mobike is not considered a 145 mobility management protocol in general, for purposes of 146 this document, it will be so considered because it manages 147 the address map and routing between a fixed VPN endpoint 148 address and a changing local address). 150 Global Mobility Anchor Point 152 A node in the network where the mobile node maintains a 153 permanent address and a mapping between the permanent 154 address and the local temporary address where the mobile 155 node happens to be currently located. The Global Mobility 156 Anchor Point may be used for purposes of rendezvous and 157 possibly traffic forwarding. For Mobile IP [1][13], this is 158 the home agent. For HIP [4], this may be the rendezvous 159 server. For Mobike [5], this is the VPN gateway in the home 160 network. Some global mobility management protocols, such as 161 HIP, support end to end global mobility management without a 162 Global Mobility Anchor Point, at the risk of dropping a 163 connection if both sides are mobile and both move at the 164 same time. 166 Intra-Link Mobility 168 Intra-Link Mobility is mobility between wireless access 169 points within an IP Link. Typically, this kind of mobility 170 only involves Layer 2 mechanisms, so Intra-Link Mobility is 171 often called Layer 2 mobility. No IP link configuration is 172 required upon movement since the link does not change, but 173 some IP signaling may be required for the mobile node to 174 confirm whether or not the change of wireless access point 175 also resulted in a change of IP link. If the IP link 176 consists of a single access point/router combination, then 177 this type of mobility is typically absent. See Figure 1. 179 2.0 The Local Mobility Problem 181 The local mobility problem is restricted to providing IP 182 mobility management for mobile nodes within an access network. 183 The access network gateways function as aggregation routers. In 184 this case, there is no specialized routing protocol (e.g. GTP, 185 Cellular IP, Hawaii, etc.) and the routers form a standard IP 186 routed network (e.g. OSPF, IS-IS, RIP, etc.). This is 187 illustrated in Figure 1, where the access network gateway 188 routers are designated as "ANG". Transitions between service 189 providers in separate autonomous systems or across broader 190 topological "boundaries" within the same service provider are 191 excluded. 193 Figure 1 depicts the scope of local mobility in comparison to 194 global mobility. The Access Network Gateways (ANGs) GA1 and GB1 195 are gateways to their access networks. The Access Routers (ARs) 196 RA1 and RA2 are in access network A, RB1 is in access network 197 B. Note that it is possible to have additional aggregation 198 routers between ANG GA1 and ANG GB1 and the access routers if 199 the access network is large. Access Points (APs) PA1 through 200 PA3 are in access network A, PB1 and PB2 are in access network 201 B. Other ANGs, ARs, and APs are also possible, and other 202 routers can separate the ARs from the ANGs. The figure implies 203 a star topology for the access network deployment, and the star 204 topology is the primary one of interest since it is quite 205 common, but the problems discussed here are equally relevant to 206 ring or mesh topologies in which ARs are directly connected 207 through some part of the network. 209 Access Network A Access Network B 211 +-------+ +-------+ 212 |ANG GA1| (other ANGs) |ANG GB1| (other ANGs) 213 +-------+ +-------+ 214 @ @ @ 215 @ @ @ 216 @ @ @ (other routers) 217 @ @ @ 218 @ @ @ 219 @ @ @ 220 +------+ +------+ +------+ 221 |AR RA1| |AR RA2|(other ARs) |AR RB1| (other ARs) 222 +------+ +------+ +------+ 223 * * * 224 * * * * * 225 * * * * * 226 * * * * * 227 * * * * * 228 * * * (other APs) * * (other APs) 229 /\ /\ /\ /\ /\ 230 /AP\ /AP\ /AP\ /AP\ /AP\ 231 /PA1 \ /PA2 \ /PA3 \ /PB1 \ /PB2 \ 232 ------ ------ ------ ------ ------ 234 +--+ +--+ +--+ +--+ 235 |MN|----->|MN|----->|MN|-------->|MN| 236 +--+ +--+ +--+ +--+ 237 Intra-link Local Global 238 (Layer 2) Mobility Mobility 239 Mobility 241 Figure 1. Scope of Local and Global Mobility Management 243 As shown in the figure, a global mobility protocol may be necessary 244 when a mobile node (MN) moves between two access networks. Exactly 245 what the scope of the access networks is depends on deployment 246 considerations. Mobility between two APs under the same AR 247 constitutes intra-link, or Layer 2, mobility, and is typically 248 handled by Layer 2 mobility protocols (if there is only one AP/cell 249 per AR, then intra-link mobility may be lacking). Between these two 250 lies local mobility. Local mobility occurs when a mobile node moves 251 between two APs connected to two different ARs. 253 Global mobility protocols allow a mobile node to maintain 254 reachability when the MN's globally routable IP address changes. It 255 does this by updating the address mapping between the permanent 256 address and temporary local address at the global mobility anchor 257 point, or even end to end by changing the temporary local address 258 directly at the node with which the mobile node is corresponding. A 259 global mobility management protocol can therefore be used between 260 ARs for handling local mobility. However, there are three well- 261 known problems involved in using a global mobility protocol for 262 every movement between ARs. Briefly, they are: 264 1) Update latency. If the global mobility anchor point and/or 265 correspondent node (for route optimized traffic) is at some 266 distance from the mobile node's access network, the global 267 mobility update may require a considerable amount of time. 268 During this time, packets continue to be routed to the old 269 temporary local address and are essentially dropped. 270 2) Signaling overhead. The amount of signaling required when a 271 mobile node moves from one IP link to another can be quite 272 extensive, including all the signaling required to configure an 273 IP address on the new link and global mobility protocol 274 signaling back into the network for changing the permanent to 275 temporary local address mapping. The signaling volume may 276 negatively impact wireless bandwidth usage and real time 277 service performance. 278 3) Location privacy. The change in temporary local address as the 279 mobile node moves exposes the mobile node's topological 280 location to correspondents and potentially to eavesdroppers. An 281 attacker that can assemble a mapping between subnet prefixes in 282 the mobile node's access network and geographical locations can 283 determine exactly where the mobile node is located. This can 284 expose the mobile node's user to threats on their location 285 privacy. A more detailed discussion of location privacy for 286 Mobile IPv6 can be found in [12]. 288 These problems suggest that a protocol to localize the management 289 of topologically small movements is preferable to using a global 290 mobility management protocol on each IP link move. In addition to 291 these problems, localized mobility management can provide a measure 292 of local control, so mobility management can be tuned for 293 specialized local conditions. Note also that if localized mobility 294 management is provided, it is not strictly required for a mobile 295 node to support a global mobility management protocol since 296 movement within a restricted IP access network can still 297 be accommodated. Without such support, however, a mobile node 298 experiences a disruption in its traffic when it moves beyond the 299 border of the localized mobility management domain. 301 3.0 Scenarios for Localized Mobility Management 303 There are a variety of scenarios in which localized mobility 304 management is useful. 306 3.1 Large Campus 308 One scenario where localized mobility management would be 309 attractive is a large campus wireless LAN deployment. Having a 310 single broadcast domain for all WLAN access points doesn't scale 311 very well. Also, sometimes parts of the campus cannot be covered 312 by one VLAN for other reasons (e.g., some links are other than 313 802.3). 315 In this case, the campus is divided into separate IP links each 316 served by one or more access routers. This kind of deployment is 317 served today by wireless LAN switches that co-ordinate IP mobility 318 between them, effectively providing localized mobility management 319 at the link layer. Since the protocols are proprietary and not 320 interoperable, any deployments that require IP mobility necessarily 321 require switches from the same vendor. 323 3.2 Advanced Cellular Network 325 Next generation cellular protocols such as 802.16e [8] and Super 326 3G/3.9G [9] have the potential to run IP deeper into the access 327 network than the current 3G cellular protocols, similar to today's 328 WLAN networks. This means that the access network can become a 329 routed IP network. Interoperable localized mobility management can 330 unify local mobility across a diverse set of wireless protocols all 331 served by IP, including advanced cellular, WLAN, and personal area 332 wireless technologies such as UltraWide Band (UWB) [10] and 333 Bluetooth [11]. Localized mobility management at the IP layer does 334 not replace Layer 2 mobility (where available) but rather 335 complements it. A standardized, interoperable localized mobility 336 management protocol for IP can remove the dependence on IP layer 337 localized mobility protocols that are specialized to specific link 338 technologies or proprietary, which is the situation with today's 3G 339 protocols. The expected benefit is a reduction in maintenance cost 340 and deployment complexity. See [6] for a more detailed discussion 341 of the goals for a network-based localized mobility management 342 protocol. 344 3.3 Picocellular Network with Small But Node-Dense IP Links 346 Future radio link protocols at very high frequencies may be 347 constrained to very short, line of sight operation. Even some 348 existing protocols, such as UWB and Bluetooth, are designed for low 349 transmit power, short range operation. For such protocols, 350 extremely small picocells become more practical. Although picocells 351 do not necessarily imply "pico IP links", wireless sensors and 352 other advanced applications may end up making such picocellular 353 type networks node-dense, requiring subnets that cover small 354 geographical areas, such as a single room. The ability to aggregate 355 many subnets under a localized mobility management scheme can help 356 reduce the amount of IP signaling required on IP link movement. 358 4.0 Problems with Existing Solutions 360 Existing solutions for localized mobility management fall into 361 three classes: 363 1) Interoperable IP level protocols that require changes to the 364 mobile node's IP stack and handle localized mobility management 365 as a service provided to the mobile node by the access network, 366 2) Link specific or proprietary protocols that handle localized 367 mobility for any mobile node but only for a specific type of 368 link layer, namely 802.11 running on an 802.3 wired network 369 backhaul. 371 The dedicated localized mobility management IETF protocols for 372 Solution 1 are not yet widely deployed, but work continues on 373 standardization. Some Mobile IPv4 deployments use localized 374 mobility management. For Solution 1, the following are specific 375 problems: 377 1) The host stack software requirement limits broad usage even if 378 the modifications are small. The success of WLAN switches 379 indicates that network operators and users prefer no host stack 380 software modifications. This preference is independent of the 381 lack of widespread Mobile IPv4 deployment, since it is much 382 easier to deploy and use the network. 383 2) Future mobile nodes may choose other global mobility management 384 protocols, such as HIP or Mobike. The existing localized 385 mobility management solutions all depend on Mobile IP or 386 derivatives. 387 3) Existing localized mobility management solutions do not support 388 both IPv4 and IPv6. 389 4) Existing host-based localized mobility management solutions 390 require setting up additional security associations with network 391 elements in the access domain. 393 Market acceptance of WLAN switches has been very large, so Solution 394 2 is widely deployed and continuing to grow. Solution 2 has the 395 following problems: 397 1) Existing solutions only support WLAN networks with Ethernet 398 backhaul and therefore are not available for advanced cellular 399 networks or picocellular protocols, or other types of wired 400 backhaul. 401 2) Each WLAN switch vendor has its own proprietary protocol that 402 does not interoperate with other vendor's equipment. 403 3) Because the solutions are based on layer 2 routing, they may not 404 scale up to a metropolitan area, or local province. 406 Having an interoperable, standardized localized mobility management 407 protocol that is scalable to topologically large networks, but 408 requires no host stack involvement for localized mobility 409 management is a highly desirable solution. Mobility routing anchor 410 points within the backbone network maintain a collection of routes 411 for individual mobile nodes. The routes point to the ARs on which 412 mobile nodes currently are located. Packets for the mobile node are 413 routed to and from the mobile node through the mobility anchor 414 point. When a mobile node moves from one AR to another, the ARs 415 send a route update to the mobility anchor point. While some mobile 416 node involvement is necessary and expected for generic mobility 417 functions such as movement detection and to inform the AR about 418 mobile node movement, no specific mobile node to network protocol 419 will be required for localized mobility management itself. 421 The advantages that this solution has over the Solutions 1 and 2 422 above are as follows: 424 1) Compared with Solution 1, a network-based solution requires no 425 localized mobility management support on the mobile node and is 426 independent of global mobility management protocol, so it can 427 be used with any or none of the existing global mobility 428 management protocols. The result is a more modular mobility 429 management architecture that better accommodates changing 430 technology and market requirements. 431 2) Compared with Solution 2, an IP level network-based localized 432 mobility management solution works for link protocols other 433 than Ethernet, and for wide area networks. 435 5.0 IANA Considerations 437 There are no IANA considerations in this document. 439 6.0 Security Considerations 441 Localized mobility management has certain security considerations, 442 one of which - need for access network to mobile node security - 443 was touched on in this document. Host-based localized mobility 444 management protocols have all the security problems involved with 445 providing a service to a host. Network-based localized mobility 446 management requires security among network elements equivalent to 447 what is needed for routing information security, and security 448 between the host and network equivalent to what is needed for 449 network access, but no more. A more complete discussion of the 450 security goals for network-based localized mobility management can 451 be found in [6]. 453 7.0 References 455 7.1 Informative References 457 [1] Koodli, R., editor, "Fast Handovers for Mobile IPv6," RFC 458 4068, July, 2005. 459 [2] Soliman, H., editor, "Hierarchical Mobile IPv6 Mobility 460 Management," RFC 4140, August, 2005. 461 [3] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in 462 IPv6," RFC 3775. 463 [4] Moskowitz, R., and Nikander, P., "Host Identity Protocol (HIP) 464 Architecture", RFC 4423, May, 2006. 465 [5] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol 466 (MOBIKE)", Internet Draft, work in progress. 467 [6] Kempf, J., editor, "Goals for Network-based Localized Mobility 468 Management", Internet Draft, work in progress. 469 [7] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC 470 3753, June, 2004. 471 [8] IEEE, "Air Interface for Mobile Broadband Wireless Access 472 Systems", 802.16e, 2005. 474 [9] 3GPP, "3GPP System Architecture Evolution: Report on Technical 475 Options and Conclusions", TR 23.882, 2005, 476 http://www.3gpp.org/ftp/Specs/html-info/23882.htm. 477 [10] http://www.ieee802.org/15/pub/TG3a.htm 478 [11] Bluetooth SIG, "Specification of the Bluetooth System", 479 November, 2004, available at http://www.bluetooth.com. 480 [12] Koodli, R., "IP Address Location Privacy and Mobile IPv6: 481 Problem Statement", Internet Draft, work in progress. 482 [13] Perkins, C., editor, " IP Mobility Support for IPv4", RFC 483 3220, August, 2002. 485 8.0 Acknowledgements 487 The authors would like to acknowledge the following for 488 particularly diligent reviewing: Pekka Savola, Vijay Devarapalli, 489 Gabriel Montenegro, Peter McCann, and Vidya Narayanan. 491 9.0 Author's Addresses 493 James Kempf 494 DoCoMo USA Labs 495 181 Metro Drive, Suite 300 496 San Jose, CA 95110 497 USA 498 Phone: +1 408 451 4711 499 Email: kempf@docomolabs-usa.com 501 Kent Leung 502 Cisco Systems, Inc. 503 170 West Tasman Drive 504 San Jose, CA 95134 505 USA 506 EMail: kleung@cisco.com 508 Phil Roberts 509 Motorola Labs 510 Schaumberg, IL 511 USA 512 Email: phil.roberts@motorola.com 514 Katsutoshi Nishida 515 NTT DoCoMo Inc. 516 3-5 Hikarino-oka, Yokosuka-shi 517 Kanagawa, 518 Japan 519 Phone: +81 46 840 3545 520 Email: nishidak@nttdocomo.co.jp 522 Gerardo Giaretta 523 Telecom Italia Lab 524 via G. Reiss Romoli, 274 525 10148 Torino 526 Italy 527 Phone: +39 011 2286904 528 Email: gerardo.giaretta@tilab.com 530 Marco Liebsch 531 NEC Network Laboratories 532 Kurfuersten-Anlage 36 533 69115 Heidelberg 534 Germany 535 Phone: +49 6221-90511-46 536 Email: marco.liebsch@ccrle.nec.de 538 10.0 IPR Statements 540 The IETF takes no position regarding the validity or scope of any 541 Intellectual Property Rights or other rights that might be claimed 542 to pertain to the implementation or use of the technology described 543 in this document or the extent to which any license under such 544 rights might or might not be available; nor does it represent that 545 it has made any independent effort to identify any such rights. 546 Information on the procedures with respect to rights in RFC 547 documents can be found in BCP 78 and BCP 79. 549 Copies of IPR disclosures made to the IETF Secretariat and any 550 assurances of licenses to be made available, or the result of an 551 attempt made to obtain a general license or permission for the use 552 of such proprietary rights by implementers or users of this 553 specification can be obtained from the IETF on-line IPR repository 554 at http://www.ietf.org/ipr. 556 The IETF invites any interested party to bring to its attention any 557 copyrights, patents or patent applications, or other proprietary 558 rights that may cover technology that may be required to implement 559 this standard. Please address the information to the IETF at ietf- 560 ipr@ietf.org. 562 11.0 Disclaimer of Validity 564 This document and the information contained herein are provided on 565 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 566 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 567 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 568 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 569 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 570 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 571 PARTICULAR PURPOSE. 573 12.0 Copyright Notice 575 Copyright (C) The Internet Society (2006). This document is 576 subject to the rights, licenses and restrictions contained in BCP 577 78, and except as set forth therein, the authors retain all their 578 rights.