idnits 2.17.1 draft-chakrabarti-mobileip-privaddr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. == There are 6 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 41 has weird spacing: '...rio for mobil...' == Line 285 has weird spacing: '...gent to share...' == Line 300 has weird spacing: '...gorithm must ...' == Line 335 has weird spacing: '...le node has s...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o The home agent MUST not support overlapping private addresses for mobile node's home address. Thus it MUST assign unique private home address to each of its mobile nodes. -- 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 normative reference: RFC 3344 (ref. '2') (Obsoleted by RFC 5944) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. '5') -- Possible downref: Normative reference to a draft: ref. '6' -- No information found for - is the name correct? -- Possible downref: Normative reference to a draft: ref. '8' Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Samita Chakrabarti 3 Category: Standards Track Gabriel Montenegro 4 Title: Sun Microsystems, Inc. 5 draft-chakrabarti-mobileip-privaddr-01.txt Hidetoshi Yokota 6 Date: October 2002 KDDI R&D Laboratories, Inc. 8 Limited Private Address Support for Mobile IPv4 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. Internet-Drafts are working documents of 14 the Internet Engineering Task Force (IETF), its areas, and its 15 working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 This document is an individual contribution for consideration by the 19 Mobile IP Working Group of the Internet Engineering Task Force. 21 Distribution of this memo is unlimited. 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: 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 Copyright (C) The Internet Society 2000. All Rights Reserved. 38 Abstract 40 Reverse Tunneling for Mobile IP describes Limited Private Address 41 Scenario for mobile nodes and mobile agents. This document specifies 42 the requirements of Mobile IP components for Limited Private Address 43 Support and discusses implementation issues and options. 44 It also specifies two new Mobile IP skippable extensions for the 45 interoperability of deployment in Limited Private Address Scenarios. 46 Solutions involving Network Address Translation are out of scope of 47 this document. 49 Table of Contents 51 1. Introduction 53 2. Terminology 55 3. Mobile Node Requirements 57 4. Home Agent Requirements 59 5. Foreign Agent Requirments 61 6. Possible usage scenarios 63 7. Implementation Considerations and Limitations 65 7.1 Handling overlapping home-addresses 66 7.2 Mobile Node to Correspondent Node Communication 68 8. New Extensions for Limited Private Address Support 70 8.1 Address Type NAI Extension (AT-NAI) 71 8.2 Mobile Node considerations using AT-NAI 72 8.3 Processing AT-NAI at Foreign Agent and Home Agent 73 8.4 LPAS Agent Advertisement Extension 75 9. Other Considerations 77 10. Acknowledgements 79 11. References 81 12. Authors' and the Chairs' Addresses 83 13. Full Copyright Statement 85 1. Introduction 87 It has been deemed by the ISPs that having Mobile IP reverse tunnel 88 and Limited Private Address Support in their operating environment 89 are key to the deployment of mobile IP services, as number of 90 publicly routable IP-addresses are scarce and do not meet the 91 demand of high volume of mobile devices, such as laptops, PDAs and 92 cell-phones. Private addressed mobile nodes can be deployed in 93 3GPP2 wireless environment and as well as in both wireless and 94 wired IP networks in the enterprise realms. 96 Appendix A.4 of Reverse Tunneling for Mobile IP [1] discusses 97 Limited Privated Address Scenarios (LPAS). This document clarifies 98 LPAS and specifies the requirements of mobile nodes, home agents 99 and foreign agents which support limited usage of private home 100 addresses. It introduces two new Mobile IP [2] extensions in 101 section 8 for interoperability among deployments. 103 The private addresses [3] discussed here are limited to mobile node 104 home addresses only. The solutions discussed in the document is 105 solely based upon Mobile IP [2], Reverse Tunneling for Mobile 106 IP [1] and Mobile IP Network Access Identifier Extension for 107 IPv4 [7]. No other mechanisms such as Network Address Translators 108 etc. are part of this solution. Operation in the presence of route 109 optimization [4] is outside the scope of this document. 111 2. Terminology 113 The document uses the following terms in addition to what is 114 defined in [1] and [2]. 116 LPAS 117 Limited Privated address Scenario which can be used by ISPs 118 and enterprizes given the current state of Mobile IP 119 specifications. 121 NAI 122 Network Access Identifier used as identifier for dynamic home 123 address allocation in Mobile IP. 125 AT-NAI 126 A new NAI extension type which lets the user request for private 127 or global IP-address. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [9]. 133 3. Mobile Node Requirements 135 The following are the requirements for private home addressed 136 mobile nodes in the limited private address support scenario. 138 o Mobile node MUST obtain reverse tunnel through registration as 139 described in Reverse Tunneling for Mobile IP [1]. 141 o A mobile node MUST have unique home address in its home domain 143 o A mobile node with public co-located COA may use private home 144 address via reverse tunnel 146 o A mobile node may never visit home and always roams. An example 147 will be cell-phones. 149 o A mobile node may request for a public or private dynamic home 150 address using the new NAI extension described in section 8. 152 4. Home Agent Requirements 154 o Home Agent MUST support reverse tunnel encapsulation and 155 decapsulation and process registration request with 'T' bit 156 set. 158 o The home agent MUST not support overlapping private addresses 159 for mobile node's home address. Thus it MUST assign unique 160 private home address to each of its mobile nodes. 162 o The home agent SHOULD be able to assign private addresses out 163 of its address pool to the mobile nodes for use of home 164 addresses. This is in accordance with section 3.8 of [2]. 166 o Home agent address MUST be a publicly routable address, if it 167 is serving the roaming mobile nodes over the public internet. 168 When home agent is used in a intranet environment and it is 169 reachable by the corresponding mobile nodes and the foreign 170 agent via the intranet, then it is sufficient for the home 171 agent to have a uniquely routable address within the intranet. 173 o A home agent which implements section 8.1 of this specification, 174 can handle both private and public dynamic home-address 175 allocation simultaneously. Otherwise, it can also assign 176 public or private home address if it implements RFC2794 (see 177 section 7.2 for details). 179 5. Foreign Agent Requirements 181 o All advertising interfaces of the foreign agent MUST have 182 publicly routable care-of address. Thus, a mobile node with a 183 private address visits the foreign agent only in its publicly 184 routable network. Note: for mobility within a intranet or 185 private network, it will be sufficient if the care-of-addreses 186 of foreign agents are uniquely routable within that network. 188 o Foreign agents MUST support reverse tunneling in order to 189 support private addressed mobile nodes. If a foreign agent 190 receives a registration request from a mobile node with a 191 private address, and the mobile node has not set the 'T' bit, 192 the foreign agent SHOULD reject it. 194 o A foreign agent which implements this specification MUST 195 use LPAS agent advertisement extension described in section 8.4. 196 A foreign agent which implements RFC3024 [1] is not required to 197 implement section 8 in this document, but it SHOULD support LPAS 198 described in section A.4 of RFC3024 [1]. 200 o A foreign agent MUST disambiguate among mobile nodes with 201 conflicting private addresses by using link-layer inforamtion 202 and or home-agent information in forward and reverse paths. 204 o A foreign agent SHOULD make sure that two mobile nodes visiting 205 the same foreign agent corresponds with each other through their 206 respective home agents. This ensures that packets coming from 207 visiting mobile nodes are not directly routed to each other 208 via the foreign agent. 210 6.0 Possible Usage Scenarios 212 1) Two private addressed mobile nodes visiting same foreign agent and 213 the mobile nodes have same home agent. 215 10.10.1.2 216 +----+ IF1=COA1+-------+ 217 | MN1|------------------------| FA | 218 +----+ +------------| | 219 | IF2=COA2+-------+ 220 +---+ | 221 | | 222 +-----+ | 223 | MN2 | INTERNET 224 +-----+ | 225 10.10.3.2 | 226 | HAA1 227 +------+ 228 | HA1 | 229 +------+ 231 Note that if IF1 = IF2, then COA1 = COA2 and this is a valid 232 scenario or configuration. COA1, COA2 and HAA1 are all publicly 233 routable addresses. 235 2) Two private addressed mobile nodes visiting same foreign agent and 236 the mobile nodes have different home agent. MN1 and MN2 may or may 237 not have same (overlapping) IP -addresses. 239 10.10.1.2 240 +----+ IF1=COA1+-------+ HAA2 +-----+ 241 | MN1|------------------------| FA |---------| HA2 | 242 +----+ +------------| | +-----+ 243 | IF2=COA2+-------+ 244 +---+ | 245 | | 246 +-----+ | 247 | MN2 | INTERNET 248 +-----+ | 249 10.10.1.2 | 250 | HAA1 251 +------+ 252 | HA1 | 253 +------+ 255 Note that even if MN1 and MN2 are connected to the same FA, they are 256 logically separated by reverse tunneling, and they don't communicate each 257 other since they belong to different HAs. For the case that IF1 = IF2, 258 refer to section 7.0. 260 3) Two mobile nodes are visiting different foreign networks/foreign 261 agents, the mobile nodes actually belong to a single home agent. 263 10.10.1.2 264 +----+ IF1=COA1+-------+ HAA2 +-----+ 265 | MN1|------------------------| FA1 |-------------| HA | 266 +----+ | | INTERNET +-----+ 267 +-------+ 268 | 269 10.10.1.5 | 270 +-----+ INTERNET 271 | MN2 |-----+ | 272 +-----+ | IF2=COA2 | 273 +-------+ | 274 | | 275 +------+ 276 | FA2 | 277 | | 278 +------+ 280 7. Implementation Considerations and Limitations 282 7.1 Handling overlapping home-addresses 284 When two mobile nodes with same private addresses visit a single 285 foreign agent to share the same COA, foreign agent distinguishes 286 between the two, in both directions of packet flow. For example, 287 in forward direction, if mobile nodes use unique point to point 288 links, the foreign agent can distinguish them easily by the 289 interfaces or point-to-point link identification. 291 But the same interface identification does not apply when two mobile 292 nodes with same private home addresses visit the foreign agent 293 on the same shared link such as ethernet. In this case, the mobile 294 node's unique identification could be its link-layer address or 295 some other unique id such as mobile terminal id. 297 In the case of ethernet address being the unique identification, 298 there might be some problems with most of the existing 299 implementations. IP address to ethernet address mapping is usually 300 one-to-one, thus ethernet address lookup algorithm must consider 301 some other mobile-node specific information to match the correct 302 ethernet address for a given overlapped private home address. 304 Similar problem appears while forwarding to the reverse tunnel. 305 Appendix A.3 of RFC3024 [1] has elaborated this situation. 307 If a private addressed mobile node registers with two different 308 home agents using the same shared link or via same COA, it SHOULD 309 use different private home addresses. Thus a foreign agent should 310 use {MN's home address, HA's address, MN's unique id} to 311 distinguish packets from the same mobile node destined to different 312 reverse tunnels. Note that MN's unique identification is 313 implementation dependent. 315 7.2 Mobile Node to Correspondent Node Communication 317 From the scenarios in section 6, it can be observed that two 318 private mobile nodes can communicate with each other if their 319 home-addresses belong to the same home agent or same private 320 network. But the mobile node is not able to communicate with 321 a correspondent node in the global internet using its non-routable 322 private home-address. Note, we are assuming that there is no 323 Network Address Translator involved in address translation between 324 the correspondent node and Home agent. 326 There could be several situations as described below: 328 a) A visiting mobile node is a mulit-homed device. 329 It uses one interface to communicate with another mobile node or 330 a correspondent node in its private home network. The mobile node 331 uses the second interface to communicate with a webserver 332 in the Internet. In this scenario, the mobile node should use 333 publicly routable home-address for the second interface. 335 b) A visiting mobile node has single network interface. 336 It uses private home address for communicating with nodes 337 in the home-network. But it needs to use a global home-address 338 in order to communicate with a node in the Internet. It's 339 possible that the Home agent has different charging policies 340 depending on the type of address usage. 342 c) A visiting mobile node does not have a fixed home-address. 343 It has a Network Access Identifier and it uses Mobile IP 344 NAI [7] to get itself a home address. The mobile node needs 345 to acquire public address or private home address depending on 346 public internet access or private home network access. 348 When mobile node depends on dynamic home address assignment, it's 349 possible that it might register with different home agents for 350 obtaining private or public home-addresses. Thus a mobile node can 351 use same NAI for receiving different types of addresses. 353 Alternatively, an ISP may assign two NAIs per user, one for 354 private home address and the other for public home address. 355 Depending on ISP billing policy, the user might get charged 356 differently for using user-private@isp.com or user-public@isp.com. 358 However, it's difficult for mobile applications to switch to 359 different configurations according to Home Agent Service Options. 360 Hence this draft proposes a specification on requesting address 361 type in dynamic home address assignment for interoperability. 363 8. New Extensions for Limited Private Address Support 365 8.1 Address Type NAI (AT-NAI) Extension 367 RFC2794 specifies dynamic home address allocation using network 368 access identifier for Mobile IPv4, but it does not have any 369 provision for mobile-node to request specific address type or 370 any other specific address requirement. 372 Thus this document specifies a skippable NAI extension for 373 requesting a specific address type. 375 0 1 2 3 376 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Type | Length | Address type | MN-NAI ... 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Type TBD (skippable) [2] 383 Length The length in bytes of the MN-NAI field plus one 385 Address Type It is a 8-bit flag uniquely identifies each NAI 386 address type request. The flag is defined as 388 +-+-+-+-+-+-+-+-+ 389 |P R R R R R R R| 390 +-+-+-+-+-+-+-+-+ 391 0 1 2 3 4 5 6 7 8 393 P - Private Address 394 R - Reserved for future use 396 MN-NAI A string in the NAI format defined in [7] 398 If P bit is 0, it requests for a global IP address, otherwise it 399 specifically requests for a private home address. 400 Other reserved bits may be defined and used in future by other 401 documents for mobile nodes which have more specific address type 402 requirements. 404 The expiration period of the assignment of a home address to a 405 mobile node should not be shorter than the accepted lifetime of 406 the registration, and it should be extended when the registration 407 is successfully updated. 409 8.2 Mobile Node considerations using AT-NAI 411 A mobile node which implements this specification MUST use 412 AT-NAI extension in order to request a private or public dynamic 413 home address assignment. Any home agent which does not implement 414 this specification may ignore the extension. In this situation, 415 the mobile node gets an error back from foreign agent and it then 416 decides to try another home agent or use RFC2794 style NAI request. 417 Note that RFC2794 style NAI and AT-NAI MUST NOT be used in the 418 same registration request. 420 8.3 Processing AT-NAI at Foreign Agent and Home Agent 422 Both Foreign and Home agents which implement this specification 423 MUST be able to process the above NAI extension type. 424 If this extension is present along with regular [7] NAI extension, 425 Foreign agent should consider that as poorly formatted request. 427 Cases when agents don't implement this specification: 429 a) Only Home agent does not understand AT-NAI 430 Home agent returns an error to the foreign agent. Foreign agent 431 replies with MISSING_HOMEADDR [7] error to the mobile node. 433 b) Foreign agent does not understand AT-NAI 434 Foreign Agent replies with NONZERO_HOMEADDR_REQD [7] error 435 to the mobile node. 437 8.4 LPAS Agent Advertisement Extension 439 Foreign and Home agents which advertise Reverse Tunneling support 440 along with the following extension, MUST support the specification 441 provided in this document. Thus a mobile node which understands 442 the following extension upon receipt of an agent advertisement, 443 can safely assume that its foreign agent provides full Limited 444 Private Address Support. The recipient of home agent 445 advertisements, similarly can assume that they can receive LPAS 446 support as specified in this document. 448 The LPAS agent advertisement extension is defined as follows: 450 0 1 2 3 451 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Type | Length | Data .... 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Type TBD (Skippable) 458 Length 1 Byte 460 Data This field does not contain any relevant information. 461 It's length could be 0 or more bytes depending 462 on alignment requirement. 464 The receiver of this extension MUST use the Type field alone to 465 determine that the advertising agent supports LPAS requirements 466 specified in this document. 468 9. Other Considerations 470 Private addressed mobile nodes using Network Address Translation 471 [5] are out of scope of this document. Such situations are 472 discussed in Mobile IP NAT/NATPT traversal [6] document. However, 473 Mobile IPv6 [8] will provide a long term solution for device 474 address scalability in mobile internet. 476 10. Acknowledgements 478 The authors like to acknowledge Tom Hiller and David Welch of Lucent 479 Technologies for the idea of having private addressed only mobile 480 nodes in the MobileIP deployment scenarios. Also we acknowledge 481 Erik Nordmark of Sun Microsystems for the initial idea on 'limited' 482 private address usage as a temporary solution of Mobile IPv4 483 deployment scenario. The authors also like to thank the following 484 reviewers (in alphabetical order): Farid Adrangi (Intel), 485 Steven Glass (Sun), Milind Kulkarni (Cisco), Pete McCann (Lucent), 486 Alpesh Patel (Cisco) and Phil Roberts (Megisto) for their comments 487 and suggestions. 489 11. References 491 [1] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 3024, January 492 2001. 494 [2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. 496 [3] Rekhter, Y.et al., "Address Allocation for Private Internets", 497 RFC 1918, February, 1996. 499 [4] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", 500 Work in Progress. 502 [5] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 503 (NAT) Terminology and Considerations", RFC 2663, August 1999. 505 [6] Levkowetz, H and S. Vaarala, "Mobile IP NAT/NAPT Traversal using UDP 506 Tunnelling", draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt, 507 Work in Progress. 509 [7] Calhoun, P and C. Perkins, "Mobile IP Network Access Identifier 510 Extension for IPv4", RFC2794, March 2000. 512 [8] D. Johnson, C. Perkins., J. Arkko, "Mobility Support in IPv6", 513 draft- ietf-mobileip-ipv6-19.txt. 515 [9] S. Bradner, "Key words for use in RFCs to Indicate Requirement 516 Levels". BCP 14, RFC 2119, March 1997. 518 12. Authors' and Chairs' Addresses 520 Questions about this document may be directed at: 522 Samita Chakrabarti 523 Sun Microsystems 524 901 San Antonio Road 525 Palo Alto, CA 94303 526 USA 528 Phone: +1 650-786-5068 529 EMail: samita.chakrabarti@Sun.com 531 Gabriel E. Montenegro 532 Sun Microsystems 533 Laboratories, Europe 534 29, chemin du Vieux Chene 535 38240 Meylan 536 FRANCE 538 Phone: +33 476 18 80 45 539 EMail: gab@sun.com 541 Hidetoshi Yokota 542 Mobile IP Network Laboratory 543 KDDI R&D Laboratories, Inc. 544 2-1-15 Ohara, Kamifukuoka Saitama 356-8502 545 JAPAN 547 Phone: +81 (492) 78-7894 548 Fax: +81 (492) 78-7510 549 EMail: yokota@kddlabs.co.jp 551 The working group can be contacted via the current chairs: 553 Basavaraj Patil 554 Nokia Networks 555 6000 Connection Drive 556 Irving, TX 75039 557 USA 559 Phone: +1 972-894-6709 560 Fax : +1 972-894-5349 561 EMail: Raj.Patil@nokia.com 562 Phil Roberts 563 Megisto Systems, Inc. 565 EMail: proberts@megisto.com 567 Gabriel E. Montenegro 568 Sun Microsystems 569 Laboratories, Europe 570 29, chemin du Vieux Chene 571 38240 Meylan 572 FRANCE 574 Phone: +33 476 18 80 45 575 EMail: gab@sun.com 577 13. Full Copyright Statement 579 Copyright (C) The Internet Society (2001). All Rights Reserved. 581 This document and translations of it may be copied and furnished to 582 others, and derivative works that comment on or otherwise explain it 583 or assist in its implementation may be prepared, copied, published 584 and distributed, in whole or in part, without restriction of any 585 kind, provided that the above copyright notice and this paragraph are 586 included on all such copies and derivative works. However, this 587 document itself may not be modified in any way, such as by removing 588 the copyright notice or references to the Internet Society or other 589 Internet organizations, except as needed for the purpose of 590 developing Internet standards in which case the procedures for 591 copyrights defined in the Internet Standards process must be 592 followed, or as required to translate it into languages other than 593 English. 595 The limited permissions granted above are perpetual and will not be 596 revoked by the Internet Society or its successors or assigns. 598 This document and the information contained herein is provided on an 599 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 600 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 601 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 602 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 603 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.