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