idnits 2.17.1 draft-lear-middlebox-arch-01.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 683 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 9 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 359: '... SHOULD do so with a request for all...' RFC 2119 keyword, line 379: '...s. If it does so, it MUST also return...' RFC 2119 keyword, line 447: '...ts - both middle box and client - MUST...' RFC 2119 keyword, line 448: '... MUST MUST implement appropriate con...' RFC 2119 keyword, line 462: '...mal connection attempts the iHOST MUST...' 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 31, 2001) is 8484 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 545 -- Looks like a reference, but probably isn't: 'RSIP' on line 505 == Unused Reference: '1' is defined on line 576, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 579, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 581, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 583, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 586, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 590, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 593, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 596, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 599, 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 (~~), 11 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 31, 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, one of the following cases must be true: 200 1. The AC must maintain topological awareness, so that it can 201 determine which middle boxes are involved. It might do this by 202 monitoring and examining link state information from the IGP. 203 2. The AC is configured with the address of a middle box and the 204 middle box must then refer the request to other appropriate middle 205 boxes, as necessary. In this case either the middle box has sufficient 206 topological knowledge or the request must be flooded to all middle 207 boxes. 209 This model may require no new signaling between iHOSTs and middle 210 boxes, so long as the AC provides any required server functionality. 212 4.2.2 Direct Signaling 214 In the second case, no AC is required. Instead, an iHOST must 215 determine that a middle box exists, signal to it for end to end 216 configuration information, and then proceed. Furthermore, the iHOST 217 must determine when the path to the oHOST has changed during a 218 session. The application should recover as circumstances dictate. 220 In this model it is important for the end host to determine that not 221 only has a failure occurred, but that the failure occurred due to 222 something the middle box could see or control. 224 ______________________________ 225 | | 226 | Private Realm | 227 | | 228 | | 229 | | ------- [oHOST] 230 | >------2--------v | / \ 231 | [iHOST]<-----1--------[middle box] |Internet| 232 | ^<------3--------v | \ / 233 | | \------/ 234 | | 235 ------------------------------- 237 1. Diagnostic/discovery, a message or messages that indicate that the 238 middle box requires attention. This message is sent in response to an 239 attempt by iHOST to start a session with oHOST that the middle box knows 240 will not succeed. 241 2. Signaling request from iHOST to middle box. 242 3. Response from middle box. 244 Note that in this model there is no AC. 246 However, the middle box must be prepared to signal to an iHOST that 247 it is being contacted. And indeed this mechanism will only work 248 reasonably if it is integrated with DNS to allow for temporary 249 allocation of addresses at the time of a query. It is a policy 250 decision for the middlebox to determine when such addresses should be 251 allocated. 253 4.2.3 Current use of Application Layer Gateways 255 An alternative model would be for end hosts to use application layer 256 gateways to access external resources. This model requires no new 257 generic signaling, but a method for each iHOST to determine when it 258 should use an application layer gateway, and when it should 259 communicate directly with another iHOST. 261 In this case, because the ALG is a middle box, it follows that this 262 method requires the ALG to reside on the perimeter of the 263 administrative domain. 265 We mention this model not merely for completeness, but because it is 266 the operative model for many applications that would eventually use 267 one of the other two models. Its clear benefit is that it exists 268 today. Furthermore, there may be benefits to having ALGs reside on 269 the perimeter. For instance, these devices will be able to 270 statefully inspect each and every packet to and from an internal 271 network. 273 4.3 Which model should we build? 275 The astute reader will notice that the direct model is very close to 276 a superset of the proxy model. The proxy model needs a signaling 277 mechanism between the AC and the middle box. There is no reason that 278 signaling mechanism couldn't be the same one used by the direct 279 model. 281 Indeed as diagnostics are introduced they can enhance both the proxy 282 model and the ALG model by returning decent diagnostics to the end 283 user when iHOST not properly configured or the AC or ALG unexpectedly 284 falls outside the data stream. 286 5 Diagnostics and Discovery 288 As mentioned in the introduction, we elide the diagnostics and 289 discovery functions in this architecture. No matter which of the 290 above models is implemented diagnostics are required to indicate to 291 the users and application when a failure has occurred. These 292 failures can take numerous forms, but here are some examples: 294 o A middle box might reboot and lose state of which holes are 295 meant to have been open. 296 o The traffic may be rerouted to an unsuspecting middle box. 297 o The application on iHOST may be unaware of a middle box for 298 which an information exchange is required. 299 o An AC may be misconfigured to prevent the iHOST from 300 establishing a session with an oHOST. 302 The diagnostic mechanism used on the Internet is ICMP. When a middle 303 box detects an attempt by an iHOST to start a session to an oHOST 304 that will not succeed, it should send a message back to the iHOST 305 indicating that a failure is likely. The content of that ICMP 306 message is discussed separately in [BLOCKER]. 308 Of the two models mentioned in Section 4, discovery may be different. 309 With the proxy model it is fairly easy to configure by hand a 310 relatively small number of ACs. Indeed either ACs must know about 311 the middle boxes or the middle boxes must know about them, since ACs 312 do not sit within the packet flow. 314 With the direct signaling model it is possible to piggyback discovery 315 on top of the diagnostic message discussed earlier. 317 6 Signaling 319 Once the application has determined that it must communicate with a 320 middle box in order for a communication to properly proceed, either 321 the AC or the iHOST initiates an exchange with the middle box. The 322 nature of this exchange depends on the function of the middle box. 323 For instance, if the middle box is a firewall, the application is in 324 essence asking permission from the firewall for the communication to 325 proceed. If, on the other hand, the box is a NAT or NAPT, the middle 326 box may merely need to know the mapping between the two addressing 327 realms for the communication. These two functions can be combined, 328 and it is reasonable to do so in order to reduce signaling overhead. 330 Any signaling requests to reserve address space or open pinholes must 331 be matched with similar requests to undo what was done. However, 332 firewalls will as a matter of policy not trust that all went well. 333 Indeed they should be fairly conservative to reduce the risk that 334 pinholes have not been left open beyond their legitimate purposes. 336 6.1 Firewalls 338 Firewalls require sufficient information about the communication to 339 determine whether or not it is authentic and whether or not it is 340 authorized. The firewall may query the application for specific 341 information necessary for authorization, but we can assume that 342 during the initial contact the firewall will need at least the 343 following information: 345 1. Protocol to be used during a session 346 2. IP address and source port of the iHOST 347 3. IP address and source port of the oHOST 348 4. One or more methods to indicate when the session has ended. 350 The firewall may also wish to know what person is initiating the 351 request, the application that is being used, or even perhaps a token 352 of some form. While it might wish to have arbitrary amounts of 353 information in order to make its decision, applications need to be 354 aware of the sorts of information the firewall will demand. Thus, 355 the names and formats of the values of the requested information must 356 be standardized, and should be managed by IANA. 358 If a firewall is going to respond to a request from an iHOST or AC it 359 SHOULD do so with a request for all the information it needs in 360 response to an initial request from either the iHOST or AC. 362 The format of the query the firewall makes must be standardized, as 363 should the names and formats of the individual attributes. 365 A firewall may accept, reject, or ignore such signaling requests. If 366 the firewall accepts a request it should respond with the protocol, 367 source and destination IP addresses and ports, confirming the way the 368 communication shall be terminated. In addition, it may return 369 additional information, as requested. This brings us to NATs. 371 Note that even if a communication is initially authorized, nothing we 372 state here should prevent or even discourage further stateful 373 inspection of any communication. 375 6.2 NATs 377 An AC or iHOST may request the port and IP address mapping between 378 two realms as part of the query discussed above. The middle box may 379 return the appropriate mappings. If it does so, it MUST also return 380 connection termination conditions. 382 Just as NATs work today mappings may be created prior to any 383 signaling exchange between the middle box and the AC or iHOST. 385 6.3 Termination Conditions 387 It is important for the middle box and the application (AC or iHOST) 388 to agree on when a session has ended. In the case of a firewall it 389 is critical that it properly close the pinhole it opened. In the 390 case of a NAT, once a session has terminated the NAT may reallocate 391 addressees and ports to another iHOST. 393 Termination conditions can be one of several methods: 395 1. A period of time, similar to a TTL used by DHCP. 396 2. A requirement that the application tell the middle box when the 397 communication has ended. 398 3. An easily discernable in stream method to determine that the 399 session is over. For instance, a TCP session ends with the exchange of 400 FINs, followed by their acknowledgement. Such methods should be 401 described in an RFC. 403 While an application might request one or more method it is up to the 404 middle box to decide which method to employ. If more than one method 405 is contained within a request or a response, the termination 406 condition that occurs soonest will be used. 408 For example, an H.323 gateway might request a UDP connection from the 409 iHOST on port 7499 to oHOST on port 8233. The AC might also request 410 that it tell the middle box when the session is terminated. A 411 firewall might respond that it has opened a pinhole as described, and 412 the termination conditions are that the AC will indicate the 413 completion of the session AND the session will be considered closed 414 after five minutes. 416 Prior to the expiration of the TTL, if the call is still active, the 417 AC might further request additional time from the middle box. 419 6.4 Communication between middle boxes 421 Although it is theoretically possible for middle boxes to exchange 422 connection state amongst each other, the overhead for doing so may 423 well prove quite high, and the value is dubious. If a middle box 424 fails it is possible that a hot spare would be able to take over its 425 responsibilities. There exists at least one document that considers 426 this possibility [YAKOV et.al]. However, we choose not to 427 standardize this function at this time. 429 More likely the case will be that any existing connections will fail 430 due to a topological change, either the middle box failing or a route 431 to the middle box failing. Therefore, it is important that end hosts 432 be able to re-establish communications and retain state above the 433 transport layer, as is necessary and appropriate. 435 6.5 Signaling Protocol Choice 437 Returning to the discussion of the two different models discussed in 438 Section 4, we note that there are subtle differences in expected 439 protocol characteristics between the proxy and direct models. In the 440 case of the direct model an iHOST could expect to issue a single 441 request per session. However, in the case of a proxy, it is likely 442 to make many requests to the middle box on behalf many client iHOSTs. 444 The signaling protocol should allow for ease of failover. In 445 addition, the protocol should also take minimal resources on both 446 client and middle box. The client itself may be a middle box. In any 447 event the signaling end points - both middle box and client - MUST 448 MUST MUST implement appropriate congestion control mechanisms. 450 6.6 Direction of Initiation 452 In the most straight forward case, either the iHOST or the AC would 453 initiate signaling to a middle box or group of middle boxes. This is 454 the simple case, and as we have seen, it's not all that simple. 456 The harder case occurs when an oHOST needs to communicate with an 457 iHOST, and wishes to initiate communication. Now, all the same 458 roadblocks may need to be cleared, only neither the iHOST nor the AC 459 is aware of need to do so. Possibly the middle box may transmit a 460 diagnostic to the iHOST or AC, indicating the initiation attempt. 461 Sufficient information must be sent so that the signaling request can 462 be initiated. Just as in normal connection attempts the iHOST MUST 463 properly handle the case where it does not wish to allow the 464 connection. It would indicate this by not signaling back to the 465 middle box or AC. 467 7 Multiple Middle Boxes 469 When used with the direct model, a diagnostic message such as ICMP 470 allows the application on an iHOST to determine not only that a 471 middle box is in its path, but also which middle box is in its path. 472 Once the iHOST identifies the middle box it can signal to it. Should 473 the data path change so that another middle box is chosen, the iHOST 474 will once again receive a notification. 476 Depending on the application or environment it may be possible for an 477 iHOST to fail over between two middle boxes that are sharing state. 478 Such failures must be transparent to the iHOST at all layers. 480 As mentioned earlier, the matter of multiple middle boxes is somewhat 481 more complex with the proxy model. Because the AC is not in the data 482 flow it must go to some additional measures to determine that a 483 middle box has failed. Indeed once the AC has determined that a 484 particular middle box has failed, or that a path has changed, it must 485 communicate appropriate information back to the iHOST. Thus, unless 486 the application already anticipates appropriate failure and restart 487 conditions, modifications may be required, defeating the usefulness 488 of the proxy model. 490 There is one additional case to be considered. When an iHOST attempts 491 to communicate across several concentric boundaries it might require 492 several rounds of signaling before a session could proceed. The 493 fastest way for signaling to proceed within the direct model is for 494 the middle box to forward a packet that has generated a diagnostic, 495 so that the very same packet could cause the next middle box to 496 generate a diagnostic as well, etc. 498 Note that there are a number of deployment scenarios one could create 499 in which the signaling itself could create a diagnostic from a middle 500 box. We declare such scenarios a matter of bad implementation and 501 deployment. 503 8 The Stack Simplification Act of 2001 505 Some mechanisms such as [RSIP] significantly complicate the host 506 stack by not giving sufficient guidance as to when the mechanism 507 should be used. 509 We propose that there are only three alternatives: 511 1. the application relies on the host's network layer to get the 512 packets directly to the other end; 513 2. the application communicates with a service that identifies 514 failures and optionally enables a flow; 515 3. the application is explicitly configured to use an application 516 layer gateway. 518 Option 2 is of great concern, in as much as the host must properly 519 multiplex any messages to an application, and those messages may need 520 to be received out of band of the normal communication. 522 9 Future Work 524 The first effort necessary is to conclude in fact whether or not 525 additional diagnostics are necessary. If so, we must next determine 526 the exact mechanisms to deliver those diagnostics. We must further 527 agree on whether or not additional discovery mechanisms should be 528 employed. 530 This document focuses on unicast based applications. We believe it 531 provides sufficient flexibility to allow for design of multicast 532 applications that take advantage of those building blocks, but more 533 study is clearly needed. 535 10 Security Considerations 537 There are numerous security considerations that middle boxes will 538 encounter, and the ones we list below should be viewed as far from 539 complete. 541 Any time a request is made for information or for a configuration 542 change it should be viewed with great suspicion. It is as of yet 543 unclear all the attacks that can be made using either the signaling 544 mechanism proposed in this document or the diagnostic messages 545 proposed in [BLOCKER]. 547 To minimize the risk of attacks, this mechanism should only be used 548 in conjunction with strong authentication and a conservative 549 authorization model. The lower bound of risk is likely that of 550 today's model, where sites generally allow outbound TCP connections. 552 The signaling, diagnostics, and discovery discussed in this draft are 553 useful only within the boundaries of a single administrative domain. 554 The middle boxes on the borders of that domain should prevent 555 external devices from participating by not transmitting diagnostic 556 messages outside, and by not listening for signaling requests on 557 interfaces external to that domain. 559 Furthermore, intrusion detection systems would be well advised to 560 look for such requests as an indication of either configuration error 561 or a possible attack. 563 The period of time between the termination of a communication and the 564 termination of pinholes in firewalls may allow for mischief. End 565 hosts must be prepared to ignore unsolicited traffic to the ports 566 involved. 568 11 IANA Considerations 570 The names of attributes and the format of their contents that a 571 middle box can either furnish or request will need to be held in a 572 registry. 574 12 References 576 [1] Rekhter et. al., "Address Allocation for Private Internets", RFC 577 1918, February 1996. 579 [4] H.323 581 [6] Carpenter, B., "Internet Transparency", RFC 2775, February 2000. 583 [7] Postel, J., "Internet Control Message Protocol", RFC 792, 584 USC/Information Sciences Institute, September 1981. 586 [9] Postel, J., ed., "Transmission Control Protocol - DARPA Internet 587 Program Protocol Specification", RFC 793, USC/Information Sciences 588 Institute, NTIS AD Number A111091, September 1981. 590 [11] Postel, J., "User Datagram Protocol", RFC 768, USC/Information 591 Sciences Institute, August 1980. 593 [12] Srisuresh, P., Holdrege, M., "IP Network Address Translator 594 (NAT) Terminology and Considerations", RFC 2663, August, 1999. 596 [13] Rekhter, Y., Bates, T., "Scalable Support for Multi-homed Multi- 597 provider Connectivity", RFC 2260, January 1998. 599 [14] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 600 March 1997. 602 BLOCKER 603 RSIP 605 13 Author's Address 607 Eliot Lear 608 Cisco Systems, Inc. 609 170 W. Tasman Dr. 610 San Jose, CA 95134-1706 611 Email: lear@cisco.com 612 Phone: +1 (408) 527 4020 614 14 Intellectual Property Statement 616 The IETF takes no position regarding the validity or scope of any 617 intellectual property or other rights that might be claimed to 618 pertain to the implementation or use of the technology described in 619 this document or the extent to which any license under such rights 620 might or might not be available; neither does it represent that it 621 has made any effort to identify any such rights. Information on the 622 IETF's procedures with respect to rights in standards-track and 623 standards-related documentation can be found in BCP-11. Copies of 624 claims of rights made available for publication and any assurances 625 of licenses to be made available, or the result of an attempt made 626 to obtain a general license or permission for the use of such 627 proprietary rights by implementors or users of this specification 628 can be obtained from the IETF Secretariat. 630 The IETF invites any interested party to bring to its attention any 631 copyrights, patents or patent applications, or other proprietary 632 rights which may cover technology that may be required to practice 633 this standard. Please address the information to the IETF Executive 634 Director. 636 16 Full Copyright Statement 638 Copyright (C) The Internet Society (2000). All Rights Reserved. 640 This document and translations of it may be copied and furnished to 641 others, and derivative works that comment on or otherwise explain it 642 or assist in its implementation may be prepared, copied, published 643 and distributed, in whole or in part, without restriction of any 644 kind, provided that the above copyright notice and this paragraph 645 are included on all such copies and derivative works. However, this 646 document itself may not be modified in any way, such as by removing 647 the copyright notice or references to the Internet Society or other 648 Internet organizations, except as needed for the purpose of 649 developing Internet standards in which case the procedures for 650 copyrights defined in the Internet Standards process must be 651 followed, or as required to translate it into languages other than 652 English. The limited permissions granted above are perpetual and 653 will not be revoked by the Internet Society or its successors or 654 assigns. This document and the information contained 655 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 656 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 657 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 658 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 659 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 660 PARTICULAR PURPOSE." 662 17 Expiration Date 664 This memo is filed as , and expires 665 July 31, 2001.