idnits 2.17.1 draft-lear-middlebox-arch-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 642 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 344: '... SHOULD do so with a request for all...' RFC 2119 keyword, line 364: '...s. If it does so, it MUST also return...' RFC 2119 keyword, line 429: '...ts - both middle box and client - MUST...' RFC 2119 keyword, line 430: '... MUST MUST implement appropriate con...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 3, 2001) is 8515 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'BCP5' on line 50 -- Looks like a reference, but probably isn't: 'AC' on line 126 -- Looks like a reference, but probably isn't: 'BLOCKER' on line 509 -- Looks like a reference, but probably isn't: 'RSIP' on line 469 == Unused Reference: '1' is defined on line 540, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 543, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 545, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 547, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 550, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 554, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. '9') (Obsoleted by RFC 9293) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Eliot Lear 2 INTERNET-DRAFT Cisco Systems 3 Category: Informational 5 6 January 3, 2001 8 A Middle Box Architectural Framework 10 1 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Copyright Notice 33 Copyright (C) The Internet Society (2000). All Rights Reserved. 35 2 Abstract 37 It used to be reasonable to expect that any two points connected to 38 the Internet to have the ability to hold any communication. Such an 39 expectation has not be reasonable for quite some time, thanks to 40 firewalls, NATs, and other intermediate devices. Today, we 41 acknowledge a new architecture and we name the functional blocks of 42 that architecture as well as several ways to get ends to communicate, 43 and how two devices could expect to communicate with each other. 44 This document does not define the protocols involved. 46 3 Introduction 48 The IPv4 Internet consists of a network of interconnected networks 49 that may use public or private address space. The use of private 50 address space [BCP5] has broken the classic connection model that 51 applications use to speak to other devices. Similarly, many networks 52 are separated by firewalls. 54 Now we consider the components necessary for end to end 55 communications in this environment, as well as the forms of signaling 56 necessary for those communications to occur in a reliable way. 58 The reader should be familiar with RFCs 1918, 2663, and 2775. We do 59 not intend to fix all problems related to NATs or firewalls with this 60 architecture. For instance, one will not find below a way to save a 61 TCP connection in the face of a NAT failure. 63 3.1 Motivation 65 The currently envisioned sets of applications to make use of this 66 architecture are voice and video conferencing and telephony. Others 67 may follow. Today voice and video capture a small percentage of 68 total network usage. As demand for these uses grows it will become 69 more important that we have in place mechanisms that have proper 70 scaling properties. 72 3.2 Goals, Terms, and Limits 74 Here are our design goals: 76 1. Enable hosts within different administrative domains and address 77 realms to have end to end sessions. 78 2. The architecture must allow for multiple middle boxes that connect 79 one realm to multiple realms. 80 3. Enable this with a minimal amount of signaling from the end host, 81 and no new signaling beyond administratively defined boundaries. 82 4. The recommended methods must not radically alter the end host stack 83 below the application. 84 5. Work within the existing interior and exterior routing framework. 85 6. The mechanisms used must easily integrate with the existing 86 Internet mechanisms and services. 88 The three middle box processes we consider in this document are 89 discovery, diagnostics, and signaling. Discovery means determining 90 that one or more middle box sits between a host end the remote end of 91 a session. Once that box is discovered, either an end host or its 92 proxy will exchange information with it in order for the 93 communication to proceed. Diagnostics is the untimely discovery of a 94 problem involving a middle box. Discovery and diagnostics differ in 95 that an end host may receive a diagnostic message from one middle box 96 while it might need to discover a separate middle box in order for 97 the communication to proceed. The architecture we propose elides the 98 two functions. 100 No changes are made to the layer 3 routing mechanism, other than the 101 possible addition of a new ICMP message to be multiplexed back to the 102 responsible application. To do otherwise would dramatically increase 103 implementation cost and complexity, as well as the cost of 104 troubleshooting problems. While the host may signal for additional 105 information to and from the application layer, it cannot rely on new 106 layer 3 routing facilities within the network. 108 Nothing this architecture proposes may stop two oHOSTs from 109 communicating with each other without the help of a middle box. 110 Similarly, this architecture must not prevent two iHOSTS from 111 communicating, just as they would have previously. However, for all 112 the reasons listed in RFC 2775 it is not possible for a middle box to 113 enable all forms of communication between iHOSTs and oHOSTs. The 114 recommended method to clear at least some of these roadblocks is the 115 wide deployment of IP version 6. 117 4 Architectural Components and Terms 119 We now define components of the architecture based on the following 120 diagram: 122 ______________________________ 123 | | 124 | Private Realm | 125 | | 126 | [AC] | 127 | | ------- [oHOST] 128 | | / \ 129 | [iHOST] [middle box] |Internet| 130 | | \ / 131 | [iHOST] | \------/ 132 | | 133 ------------------------------- 135 A private realm consists either of hosts that are numbered within the 136 space defined by BCP 5 or hosts that sit within a single security 137 domain. An iHOST is a host that sits within that realm. An oHOST 138 sits outside the private address realm. It may be assigned public 139 address space or private address space. In the latter case it would 140 sit within its own private address realm. An AC is an application 141 controller. An application controller may be an application layer 142 gateway, or it may merely arrange for communication between two 143 hosts, be they iHOSTs or oHOSTs. An AC may itself be a middle box. 145 A middle box is a device that sits on the edge of a private realm. 146 It is the responsibility of the middle box to police or transform 147 sessions from its private realm to the outside world. Middle boxes 148 consist of firewalls, NATs and other devices that sit within the flow 149 of packets and may impact a session from an iHOST to an oHOST. At 150 the border of a private realm there may be multiple middle boxes that 151 connect the realm to other realms. 153 The remainder of this document refers to communications between an 154 iHOST and an oHOST. 156 4.2 Communication Models 158 No matter the model we assume that iHOSTS may only signal to middle 159 boxes that exist within the same administrative domain. 161 There are two models of communication we will consider. The first 162 model may not require end host application changes, but rather 163 requires changes to servers that assist end hosts in communicating 164 with each other. The second model allows end hosts themselves to 165 exchange information with the intermediate devices. These two models 166 differ significantly. 168 4.2.1 Proxy Signaling 170 In the first case, iHOSTs use something akin to an application layer 171 gateway to first arrange a session. We will generically refer to 172 such a box as an application controller (AC). An example would be 173 H.225 signaling between an H.323 end point and a gate keeper. As the 174 gatekeeper processes call setup information it would communicate with 175 any middle box necessary for the end points to establish end to end 176 connectivity. This model is best employed when there already exists 177 some sort of application controller, since no additional signaling 178 may be necessary between the iHOST and the AC. Either the end 179 application is required to know of the AC or the AC must reside 180 within the data path between the iHOST and oHOST. 182 ______________________________ 183 | | 184 | Private Realm | 185 | | 186 | --- 1 --> [AC]->v | 187 | / v | 188 | / 2 | 189 | | v | ------- [oHOST] 190 | | v | / \ ^ 191 | [iHOST]-----3-------->[middle box]--->|Internet|---3---->^ 192 | | \ / 193 | [iHOST] | \------/ 194 | | 195 ------------------------------- 197 In order for the end hosts to continue sessions with some level of 198 reliability the AC must maintain topological awareness, so that it 199 can determine which middle boxes are involved. It might do this by 200 monitoring and examining link state information from the IGP. 201 However, no new signaling would be required between iHOSTs and middle 202 boxes. 204 4.2.2 Direct Signaling 206 In the second case, no AC is required. Instead, an iHOST must 207 determine that a middle box exists, signal to it for end to end 208 configuration information, and then proceed. Furthermore, the iHOST 209 must determine when the path to the oHOST has changed during a 210 session. The application should recover as circumstances dictate. 212 In this model it is important for the end host to determine that not 213 only has a failure occurred, but that the failure occurred due to 214 something the middle box could see or control. 216 ______________________________ 217 | | 218 | Private Realm | 219 | | 220 | | 221 | | ------- [oHOST] 222 | >------2--------v | / \ 223 | [iHOST]<-----1--------[middle box] |Internet| 224 | ^<------3--------v | \ / 225 | | \------/ 226 | | 227 ------------------------------- 229 1. Diagnostic/discovery, a message or messages that indicate that the 230 middle box requires attention. This message is sent in response to an 231 attempt by iHOST to start a session with oHOST that the middle box knows 232 will not succeed. 233 2. Signaling request from iHOST to middle box. 234 3. Response from middle box. 236 Note that in this model there is no AC. 238 4.2.3 Current use of Application Layer Gateways 240 An alternative model would be for end hosts to use application layer 241 gateways to access external resources. This model requires no new 242 generic signaling, but a method for each iHOST to determine when it 243 should use an application layer gateway, and when it should 244 communicate directly with another iHOST. 246 In this case, because the ALG is a middle box, it follows that this 247 method requires the ALG to reside on the perimeter of the 248 administrative domain. 250 We mention this model not merely for completeness, but because it is 251 the operative model for many applications that would eventually use 252 one of the other two models. Its clear benefit is that it exists 253 today. Furthermore, there may be benefits to having ALGs reside on 254 the perimeter. For instance, these devices will be able to 255 statefully inspect each and every packet to and from an internal 256 network. 258 4.3 Which model should we build? 260 The astute reader will notice that the direct model is very close to 261 a superset of the proxy model. The proxy model needs a signaling 262 mechanism between the AC and the middle box. There is no reason that 263 signaling mechanism couldn't be the same one used by the direct 264 model. 266 Indeed as diagnostics are introduced they can enhance both the proxy 267 model and the ALG model by returning decent diagnostics to the end 268 user when iHOST not properly configured or the AC or ALG unexpectedly 269 falls outside the data stream. 271 5 Diagnostics and Discovery 273 As mentioned in the introduction, we elide the diagnostics and 274 discovery functions in this architecture. No matter which of the 275 above models is implemented diagnostics are required to indicate to 276 the users and application when a failure has occurred. These 277 failures can take numerous forms, but here are some examples: 279 o A middle box might reboot and lose state of which holes are 280 meant to have been open. 281 o The traffic may be rerouted to an unsuspecting middle box. 282 o The application on iHOST may be unaware of a middle box for 283 which an information exchange is required. 284 o An AC may be misconfigured to prevent the iHOST from 285 establishing a session with an oHOST. 287 The diagnostic mechanism used on the Internet is ICMP. When a middle 288 box detects an attempt by an iHOST to start a session to an oHOST 289 that will not succeed, it should send a message back to the iHOST 290 indicating that a failure is likely. The content of that ICMP 291 message is discussed separately in [BLOCKER]. 293 Of the two models mentioned in Section 4, discovery may be different. 294 With the proxy model it is fairly easy to configure by hand a 295 relatively small number of ACs. Indeed either ACs must know about 296 the middle boxes or the middle boxes must know about them, since ACs 297 do not sit within the packet flow. 299 With the direct signaling model it is possible to piggyback discovery 300 on top of the diagnostic message discussed earlier. 302 6 Signaling 304 Once the application has determined that it must communicate with a 305 middle box in order for a communication to properly proceed, either 306 the AC or the iHOST initiates an exchange with the middle box. The 307 nature of this exchange depends on the function of the middle box. 308 For instance, if the middle box is a firewall, the application is in 309 essence asking permission from the firewall for the communication to 310 proceed. If, on the other hand, the box is a NAT or NAPT, the middle 311 box may merely need to know the mapping between the two addressing 312 realms for the communication. These two functions can be combined, 313 and it is reasonable to do so in order to reduce signaling overhead. 315 Any signaling requests to reserve address space or open pinholes must 316 be matched with similar requests to undo what was done. However, 317 firewalls will as a matter of policy not trust that all went well. 318 Indeed they should be fairly conservative to reduce the risk that 319 pinholes have not been left open beyond their legitimate purposes. 321 6.1 Firewalls 323 Firewalls require sufficient information about the communication to 324 determine whether or not it is authentic and whether or not it is 325 authorized. The firewall may query the application for specific 326 information necessary for authorization, but we can assume that 327 during the initial contact the firewall will need at least the 328 following information: 330 1. Protocol to be used during a session 331 2. IP address and source port of the iHOST 332 3. IP address and source port of the oHOST 333 4. One or more methods to indicate when the session has ended. 335 The firewall may also wish to know what person is initiating the 336 request, the application that is being used, or even perhaps a token 337 of some form. While it might wish to have arbitrary amounts of 338 information in order to make its decision, applications need to be 339 aware of the sorts of information the firewall will demand. Thus, 340 the names and formats of the values of the requested information must 341 be standardized, and should be managed by IANA. 343 If a firewall is going to respond to a request from an iHOST or AC it 344 SHOULD do so with a request for all the information it needs in 345 response to an initial request from either the iHOST or AC. 347 The format of the query the firewall makes must be standardized, as 348 should the names and formats of the individual attributes. 350 A firewall may accept, reject, or ignore such signaling requests. If 351 the firewall accepts a request it should respond with the protocol, 352 source and destination IP addresses and ports, confirming the way the 353 communication shall be terminated. In addition, it may return 354 additional information, as requested. This brings us to NATs. 356 Note that even if a communication is initially authorized, nothing we 357 state here should prevent or even discourage further stateful 358 inspection of any communication. 360 6.2 NATs 362 An AC or iHOST may request the port and IP address mapping between 363 two realms as part of the query discussed above. The middle box may 364 return the appropriate mappings. If it does so, it MUST also return 365 connection termination conditions. 367 6.3 Termination Conditions 369 It is important for the middle box and the application (AC or iHOST) 370 to agree on when a session has ended. In the case of a firewall it 371 is critical that it properly close the pinhole it opened. In the 372 case of a NAT, once a session has terminated the NAT may reallocate 373 addressees and ports to another iHOST. 375 Termination conditions can be one of several methods: 377 1. A period of time, similar to a TTL used by DHCP. 378 2. A requirement that the application tell the middle box when the 379 communication has ended. 380 3. An easily discernable in stream method to determine that the 381 session is over. For instance, a TCP session ends with the exchange of 382 FINs, followed by their acknowledgement. Such methods should be 383 described in an RFC. 385 While an application might request one or more method it is up to the 386 middle box to decide which method to employ. If more than one method 387 is contained within a request or a response, the termination 388 condition that occurs soonest will be used. 390 For example, an H.323 gateway might request a UDP connection from the 391 iHOST on port 7499 to oHOST on port 8233. The AC might also request 392 that it tell the middle box when the session is terminated. A 393 firewall might respond that it has opened a pinhole as described, and 394 the termination conditions are that the AC will indicate the 395 completion of the session AND the session will be considered closed 396 after five minutes. 398 Prior to the expiration of the TTL, if the call is still active, the 399 AC might further request additional time from the middle box. 401 6.4 Communication between middle boxes 403 Although it is theoretically possible for middle boxes to exchange 404 connection state amongst each other, the overhead for doing so may 405 well prove quite high, and the value is dubious. If a middle box 406 fails it is possible that a hot spare would be able to take over its 407 responsibilities. There exists at least one document that considers 408 this possibility [YAKOV et.al]. However, we choose not to 409 standardize this function at this time. 411 More likely the case will be that any existing connections will fail 412 due to a topological change, either the middle box failing or a route 413 to the middle box failing. Therefore, it is important that end hosts 414 be able to re-establish communications and retain state above the 415 transport layer, as is necessary and appropriate. 417 6.5 Signaling Protocol Choice 419 Returning to the discussion of the two different models discussed in 420 Section 4, we note that there are subtle differences in expected 421 protocol characteristics between the proxy and direct models. In the 422 case of the direct model an iHOST could expect to issue a single 423 request per session. However, in the case of a proxy, it is likely 424 to make many requests to the middle box on behalf many client iHOSTs. 426 The signaling protocol should allow for ease of failover. In 427 addition, the protocol should also take minimal resources on both 428 client and middle box. The client itself may be a middle box. In any 429 event the signaling end points - both middle box and client - MUST 430 MUST MUST implement appropriate congestion control mechanisms. 432 7 Multiple Middle Boxes 434 When used with the direct model, a diagnostic message such as ICMP 435 allows the application on an iHOST to determine not only that a 436 middle box is in its path, but also which middle box is in its path. 437 Once the iHOST identifies the middle box it can signal to it. Should 438 the data path change so that another middle box is chosen, the iHOST 439 will once again receive a notification. 441 Depending on the application or environment it may be possible for an 442 iHOST to fail over between two middle boxes that are sharing state. 443 Such failures must be transparent to the iHOST at all layers. 445 The matter of multiple middle boxes is somewhat more complex with the 446 proxy model. Because the AC is not in the data flow it must go to 447 some additional measures to determine that a middle box has failed. 448 Indeed once the AC has determined that a particular middle box has 449 failed, or that a path has changed, it must communicate appropriate 450 information back to the iHOST. Thus, unless the application already 451 anticipates appropriate failure and restart conditions, modifications 452 may be required, defeating the usefulness of the proxy model. 454 There is one additional case to be considered. When an iHOST attempts 455 to communicate across several concentric boundaries it might require 456 several rounds of signaling before a session could proceed. The 457 fastest way for signaling to proceed within the direct model is for 458 the middle box to forward a packet that has generated a diagnostic, 459 so that the very same packet could cause the next middle box to 460 generate a diagnostic as well, etc. 462 Note that there are a number of deployment scenarios one could create 463 in which the signaling itself could create a diagnostic from a middle 464 box. We declare such scenarios a matter of bad implementation and 465 deployment. 467 8 The Stack Simplification Act of 2001 469 Some mechanisms such as [RSIP] significantly complicate the host 470 stack by not giving sufficient guidance as to when the mechanism 471 should be used. 473 We propose that there are only three alternatives: 475 1. the application relies on the host's network layer to get the 476 packets directly to the other end; 477 2. the application communicates with a service that identifies 478 failures and optionally enables a flow; 479 3. the application is explicitly configured to use an application 480 layer gateway. 482 Option 2 is of great concern, in as much as the host must properly 483 multiplex any messages to an application, and those messages may need 484 to be received out of band of the normal communication. 486 9 Future Work 488 The first effort necessary is to conclude in fact whether or not 489 additional diagnostics are necessary. If so, we must next determine 490 the exact mechanisms to deliver those diagnostics. We must further 491 agree on whether or not additional discovery mechanisms should be 492 employed. 494 This document focuses on unicast based applications. We believe it 495 provides sufficient flexibility to allow for design of multicast 496 applications that take advantage of those building blocks, but more 497 study is clearly needed. 499 10 Security Considerations 501 There are numerous security considerations that middle boxes will 502 encounter, and the ones we list below should be viewed as far from 503 complete. 505 Any time a request is made for information or for a configuration 506 change it should be viewed with great suspicion. It is as of yet 507 unclear all the attacks that can be made using either the signaling 508 mechanism proposed in this document or the diagnostic messages 509 proposed in [BLOCKER]. 511 To minimize the risk of attacks, this mechanism should only be used 512 in conjunction with strong authentication and a conservative 513 authorization model. The lower bound of risk is likely that of 514 today's model, where sites generally allow outbound TCP connections. 516 The signaling, diagnostics, and discovery discussed in this draft are 517 useful only within the boundaries of a single administrative domain. 518 The middle boxes on the borders of that domain should prevent 519 external devices from participating by not transmitting diagnostic 520 messages outside, and by not listening for signaling requests on 521 interfaces external to that domain. 523 Furthermore, intrusion detection systems would be well advised to 524 look for such requests as an indication of either configuration error 525 or a possible attack. 527 The period of time between the termination of a communication and the 528 termination of pinholes in firewalls may allow for mischief. End 529 hosts must be prepared to ignore unsolicited traffic to the ports 530 involved. 532 11 IANA Considerations 534 The names of attributes and the format of their contents that a 535 middle box can either furnish or request will need to be held in a 536 registry. 538 12 References 540 [1] Rekhter et. al., "Address Allocation for Private Internets", RFC 541 1918, February 1996. 543 [4] H.323 545 [6] Carpenter, B., ..., RFC 2775 547 [7] Postel, J., "Internet Control Message Protocol", RFC 792, 548 USC/Information Sciences Institute, September 1981. 550 [9] Postel, J., ed., "Transmission Control Protocol - DARPA Internet 551 Program Protocol Specification", RFC 793, USC/Information Sciences 552 Institute, NTIS AD Number A111091, September 1981. 554 [11] Postel, J., "User Datagram Protocol", RFC 768, USC/Information 555 Sciences Institute, August 1980. 557 RFC 2663 558 BLOCKER 559 RSIP 560 DHCP 561 NAT-FAILOVER (Yakov, et. al). 563 13 Author's Address 565 Eliot Lear 566 Cisco Systems, Inc. 567 170 W. Tasman Dr. 568 San Jose, CA 95134-1706 569 Email: lear@cisco.com 570 Phone: +1 (408) 527 4020 572 14 Intellectual Property Statement 574 The IETF takes no position regarding the validity or scope of any 575 intellectual property or other rights that might be claimed to 576 pertain to the implementation or use of the technology described in 577 this document or the extent to which any license under such rights 578 might or might not be available; neither does it represent that it 579 has made any effort to identify any such rights. Information on the 580 IETF's procedures with respect to rights in standards-track and 581 standards-related documentation can be found in BCP-11. Copies of 582 claims of rights made available for publication and any assurances 583 of licenses to be made available, or the result of an attempt made 584 to obtain a general license or permission for the use of such 585 proprietary rights by implementors or users of this specification 586 can be obtained from the IETF Secretariat. 588 The IETF invites any interested party to bring to its attention any 589 copyrights, patents or patent applications, or other proprietary 590 rights which may cover technology that may be required to practice 591 this standard. Please address the information to the IETF Executive 592 Director. 594 16 Full Copyright Statement 596 Copyright (C) The Internet Society (2000). All Rights Reserved. 598 This document and translations of it may be copied and furnished to 599 others, and derivative works that comment on or otherwise explain it 600 or assist in its implementation may be prepared, copied, published 601 and distributed, in whole or in part, without restriction of any 602 kind, provided that the above copyright notice and this paragraph 603 are included on all such copies and derivative works. However, this 604 document itself may not be modified in any way, such as by removing 605 the copyright notice or references to the Internet Society or other 606 Internet organizations, except as needed for the purpose of 607 developing Internet standards in which case the procedures for 608 copyrights defined in the Internet Standards process must be 609 followed, or as required to translate it into languages other than 610 English. The limited permissions granted above are perpetual and 611 will not be revoked by the Internet Society or its successors or 612 assigns. This document and the information contained 613 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 614 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 615 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 616 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 617 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 618 PARTICULAR PURPOSE." 620 17 Expiration Date 622 This memo is filed as , and expires 623 July 3, 2001.