idnits 2.17.1 draft-ietf-ipngwg-pmtuv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 123: '...et Too Big message, it MUST reduce its...' RFC 2119 keyword, line 130: '...oo Big message, a node MUST attempt to...' RFC 2119 keyword, line 131: '...ges in the near future. The node MUST...' RFC 2119 keyword, line 136: '... node MUST force the PMTU Discovery ...' RFC 2119 keyword, line 138: '...g PMTU Discovery MUST detect decreases...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'CONG' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRAG' -- Possible downref: Non-RFC (?) normative reference: ref. 'ICMPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-SPEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6' ** Downref: Normative reference to an Unknown state RFC: RFC 905 (ref. 'ISOTP') ** Downref: Normative reference to an Informational RFC: RFC 1057 (ref. 'RPC') Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. McCann, Digital Equipment Corporation 3 November 6, 1995 S. Deering, Xerox PARC 5 Path MTU Discovery for IP version 6 7 draft-ietf-ipngwg-pmtuv6-00.txt 9 Abstract 11 This document describes Path MTU Discovery for IP version 6. It is 12 largely derived from RFC-1191, which describes Path MTU Discovery for 13 IP version 4. 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Distribution of this document is unlimited. 35 Expiration 37 May 6, 1996 39 Contents 41 Abstract........................................................1 43 Status of this Memo.............................................1 45 Contents........................................................2 47 1. Introduction.................................................3 49 2. Protocol overview............................................3 51 3. Protocol Requirements........................................4 53 4. Implementation suggestions...................................4 54 4.1. Layering...................................................5 55 4.2. Storing PMTU information...................................5 56 4.3. Purging stale PMTU information.............................7 57 4.4. TCP layer actions..........................................8 58 4.5. Issues for other transport protocols.......................9 59 4.6. Management interface......................................10 61 5. Security considerations.....................................10 63 Acknowledgements...............................................11 65 References.....................................................12 67 Authors' Addresses.............................................13 69 1. Introduction 71 When one IPv6 node has a large amount of data to send to another 72 node, the data is transmitted in a series of IPv6 packets. It is 73 usually preferable that these packets be of the largest size that can 74 successfully traverse the path from the source node to the 75 destination node. This packet size is referred to as the Path MTU 76 (PMTU), and it is equal to the minimum of the MTUs of the hops in a 77 path. IPv6 defines a standard mechanism for a node to discover the 78 PMTU of an arbitrary path. 80 A PMTU is associated with a path. In IPv6, a path is identified by a 81 particular combination of source and destination IPv6 addresses, flow 82 id, and perhaps IPv6 Routing header information. 84 Nodes not implementing Path MTU Discovery use the IPv6 minimum link 85 MTU as defined in [IPv6-SPEC] as the maximum packet size. In most 86 cases, this will result in the use of smaller packets than necessary, 87 because most paths have a PMTU greater than the IPv6 minimum link 88 MTU. A node sending packets much smaller than the Path MTU allows is 89 wasting network resources and probably getting suboptimal throughput. 91 2. Protocol overview 93 This memo describes a technique to dynamically discover the PMTU of a 94 path. The basic idea is that a source node initially assumes that 95 the PMTU of a path is the (known) MTU of the first hop in the path. 96 If any of the packets sent on that path are too large to be forwarded 97 by some router along the path, that router will discard them and 98 return ICMPv6 Packet Too Big messages [ICMPv6]. Upon receipt of such 99 a message, the source node reduces its assumed PMTU for the path to 100 be equal to the MTU of the constricting hop as reported in the Packet 101 Too Big message. 103 The PMTU discovery process ends when the node's estimate of the PMTU 104 is less than or equal to the actual PMTU. Note that several 105 iterations of the packet-sent/Packet-Too-Big-message-received cycle 106 may occur before the PMTU discovery process ends, as there may be 107 hops with smaller MTUs further along the path. 109 Alternatively, the node may elect to end the discovery process by 110 ceasing to send packets larger than the IPv6 minimum link MTU. 112 The PMTU of a path may change over time, due to changes in the 113 routing topology. Reductions of the PMTU are detected by Packet Too 114 Big messages. To detect increases in a path's PMTU, a node 115 periodically increases its assumed PMTU. This will almost always 116 result in packets being discarded and Packet Too Big messages being 117 generated, because in most cases the PMTU of the path will not have 118 changed. Therefore, attempts to detect increases in a path's PMTU 119 should be done infrequently. 121 3. Protocol Requirements 123 When a node receives a Packet Too Big message, it MUST reduce its 124 estimate of the PMTU for the relevant path, based on the value of the 125 MTU field in the message. The precise behavior of a node in this 126 circumstance is not specified, since different applications may have 127 different requirements, and since different implementation 128 architectures may favor different strategies. 130 After receiving a Packet Too Big message, a node MUST attempt to 131 avoid eliciting more such messages in the near future. The node MUST 132 reduce the size of the packets it is sending along the path. Using a 133 PMTU estimate larger than the IPv6 minimum link MTU may continue to 134 elicit Packet Too Big messages. Since each of these messages (and 135 the dropped packets they respond to) consume network resources, the 136 node MUST force the PMTU Discovery process to end. 138 Nodes using PMTU Discovery MUST detect decreases in Path MTU as fast 139 as possible. Nodes MAY detect increases in Path MTU, but because 140 doing so requires sending packets larger than the current estimated 141 PMTU, and because the likelihood is that the PMTU will not have 142 increased, this MUST be done at infrequent intervals. An attempt to 143 detect an increase (by sending a packet larger than the current 144 estimate) MUST NOT be done less than 5 minutes after a Packet Too Big 145 message has been received for the given path. The recommended 146 setting for this timer is twice its minimum value (10 minutes). 148 A node MUST NOT reduce its estimate of the Path MTU below the IPv6 149 minimum link MTU [IPv6]. 151 A node MUST NOT increase its estimate of the Path MTU in response to 152 the contents of a Packet Too Big message. A message purporting to 153 announce an increase in the Path MTU might be a stale packet that has 154 been floating around in the network, a false packet injected as part 155 of a denial-of-service attack, or the result of having multiple paths 156 to the destination. 158 4. Implementation suggestions 160 This section discusses how PMTU Discovery may be implemented. This 161 is not a specification, but rather a set of suggestions. 163 The issues include: 165 - What layer or layers implement PMTU Discovery? 167 - Where is the PMTU information cached? 168 - How is stale PMTU information removed? 170 - What must transport and higher layers do? 172 4.1. Layering 174 In the IP architecture, the choice of what size packet to send is 175 made by a protocol at a layer above IP. This memo refers to such a 176 protocol as a "packetization protocol". Packetization protocols are 177 usually transport protocols (for example, TCP) but can also be 178 higher-layer protocols (for example, protocols built on top of UDP). 180 Implementing PMTU Discovery in the packetization layers simplifies 181 some of the inter-layer issues, but has several drawbacks: the 182 implementation may have to be redone for each packetization protocol, 183 it becomes hard to share PMTU information between different 184 packetization layers, and the connection-oriented state maintained by 185 some packetization layers may not easily extend to save PMTU 186 information for long periods. 188 It is therefore suggested that the IP layer store PMTU information 189 and that the ICMP layer process received Packet Too Big messages. 190 The packetization layers may respond to changes in the PMTU, by 191 changing the size of the messages they send. To support this 192 layering, packetization layers require a way to learn of changes in 193 the value of MMS_S, the "maximum send transport-message size". The 194 MMS_S is derived from the Path MTU by subtracting the size of the 195 IPv6 header plus space reserved by the IP layer for additional 196 headers (if any). 198 It is possible that a packetization layer, perhaps a UDP application 199 outside the kernel, is unable to change the size of messages it 200 sends. This may result in a packet size that exceeds the Path MTU. 201 To accommodate such situations, IPv6 defines a mechanism that allows 202 large payloads to be divided into fragments, with each fragment sent 203 in a separate packet (see [IPv6-SPEC] section "Fragment Header"). 204 However, packetization layers are encouraged to avoid sending 205 messages that will require fragmentation (for the case against 206 fragmentation, see [FRAG]). 208 4.2. Storing PMTU information 210 In general, each PMTU value learned should be associated with a 211 specific path. A path is identified by a source IPv6 address, a 212 destination IPv6 address, a flow id, and possibly IPv6 Routing header 213 information. 215 Note: Some paths may be further distinguished by different 216 security classifications. The details of such classifications are 217 beyond the scope of this memo. 219 The obvious place to store this association is as a field in the 220 routing table entries. A node will not have a route for every 221 possible destination, but it should be able to cache a per- 222 destination route for every active destination. (This requirement is 223 already imposed by the need to process ICMP Redirect messages.) 225 When the first packet is sent to a destination for which no per- 226 destination route exists, a route is chosen from the set of more 227 aggregated routes, for example a subnet route or a default route. 228 The PMTU fields in these route entries should be initialized to be 229 the MTU of the associated first-hop link, and must never be changed 230 by the PMTU Discovery process. (PMTU Discovery only creates or 231 changes entries for per-destination routes). Until a Packet Too Big 232 message is received, the PMTU associated with the initially chosen 233 route is presumed to be accurate. 235 When a Packet Too Big message is received, the ICMP layer determines 236 a new estimate for the Path MTU (from the value in the MTU field in 237 the Packet Too Big message). If a per-destination route for this 238 path does not exist, then one is created (the new route uses the same 239 first-hop router as the current route). If the PMTU estimate 240 associated with the per-destination route is higher than the new 241 estimate, then the value in the routing entry is changed. 243 The packetization layers must be notified about decreases in the 244 PMTU. Any packetization layer instance (for example, a TCP 245 connection) that is actively using the path must be notified if the 246 PMTU estimate is decreased. 248 Note: even if the Packet Too Big message contains an Original 249 Packet Header that refers to a UDP packet, the TCP layer must be 250 notified if any of its connections use the given path. 252 Also, the instance that sent the packet that elicited the Packet Too 253 Big message should be notified that its packet has been dropped, even 254 if the PMTU estimate has not changed, so that it may retransmit the 255 dropped data. 257 Note: An implementation can avoid the use of an asynchronous 258 notification mechanism for PMTU decreases by postponing 259 notification until the next attempt to send a packet larger than 260 the PMTU estimate. In this approach, when an attempt is made to 261 SEND a packet that is larger than the PMTU estimate, the SEND 262 function should fail and return a suitable error indication. This 263 approach may be more suitable to a connectionless packetization 264 layer (such as one using UDP), which (in some implementations) may 265 be hard to "notify" from the ICMP layer. In this case, the normal 266 timeout-based retransmission mechanisms would be used to recover 267 from the dropped packets. 269 It is important to understand that the notification of the 270 packetization layer instances using the path about the change in the 271 PMTU is distinct from the notification of a specific instance that a 272 packet has been dropped. The latter should be done as soon as 273 practical (i.e., asynchronously from the point of view of the 274 packetization layer instance), while the former may be delayed until 275 a packetization layer instance wants to create a packet. 276 Retransmission should be done for only for those packets that are 277 known to be dropped, as indicated by a Packet Too Big message. 279 4.3. Purging stale PMTU information 281 Internetwork topology is dynamic; routes change over time. The PMTU 282 discovered for a given destination may be wrong if a new route comes 283 into use. Thus, PMTU information cached by a node can become stale. 285 If the stale PMTU value is too large, this will be discovered almost 286 immediately once a large enough packet is sent to the given 287 destination. No such mechanism exists for realizing that a stale 288 PMTU value is too small, so an implementation should "age" cached 289 values. When a PMTU value has not been decreased for a while (on the 290 order of 10 minutes), the PMTU estimate should be set to the MTU of 291 the first-hop link, and the packetization layers should be notified 292 of the change. This will cause the complete PMTU Discovery process 293 to take place again. 295 Note: an implementation should provide a means for changing the 296 timeout duration, including setting it to "infinity". For 297 example, nodes attached to an FDDI link which is then attached to 298 the rest of the Internet via a small MTU serial line are never 299 going to discover a new non-local PMTU, so they should not have to 300 put up with dropped packets every 10 minutes. 302 An upper layer must not retransmit data in response to an increase in 303 the PMTU estimate, since this increase never comes in response to an 304 indication of a dropped packet. 306 One approach to implementing PMTU aging is to add a timestamp field 307 to the routing table entry. This field is initialized to a 308 "reserved" value, indicating that the PMTU has never been changed. 309 Whenever the PMTU is decreased in response to a Packet Too Big 310 message, the timestamp is set to the current time. 312 Once a minute, a timer-driven procedure runs through the routing 313 table, and for each entry whose timestamp is not "reserved" and is 314 older than the timeout interval: 316 - The PMTU estimate is set to the MTU of the first hop link. 318 - Packetization layers using this route are notified of the increase. 320 PMTU estimates may disappear from the routing table if the per- 321 destination routes are removed; this can happen in response to an 322 ICMPv6 Redirect message, or because certain routing-table daemons 323 delete old routes after several minutes. Also, on a multi-homed node 324 a topology change may result in the use of a different source 325 interface. When this happens, if the packetization layer is not 326 notified then it may continue to use a cached PMTU value that is now 327 too small. One solution is to notify the packetization layer of a 328 possible PMTU change whenever a Redirect message causes a route 329 change, and whenever a route is simply deleted from the routing 330 table. 332 4.4. TCP layer actions 334 The TCP layer must track the PMTU for the destination of a 335 connection; it should not send segments that would result in packets 336 larger than the PMTU. A simple implementation could ask the IP layer 337 for this value each time it created a new segment, but this could be 338 inefficient. Moreover, TCP implementations that follow the "slow- 339 start" congestion-avoidance algorithm [CONG] typically calculate and 340 cache several other values derived from the PMTU. It may be simpler 341 to receive asynchronous notification when the PMTU changes, so that 342 these variables may be updated. 344 A TCP implementation must also store the MSS value received from its 345 peer, and must not send any segment larger than this MSS, regardless 346 of the PMTU. In 4.xBSD-derived implementations, this may require 347 adding an additional field to the TCP state record. 349 The value sent in the TCP MSS option is independent of the PMTU. 350 This MSS option value is used by the other end of the connection, 351 which may be using an unrelated PMTU value. See [IPv6-SPEC] sections 352 "Packet Size Issues" and "Maximum Upper-Layer Payload Size" for 353 information on selecting a value for the TCP MSS option. 355 When a Packet Too Big message is received, it implies that a packet 356 was dropped by the router that sent the ICMP message. It is 357 sufficient to treat this as any other dropped segment, and wait until 358 the retransmission timer expires to cause retransmission of the 359 segment. If the PMTU Discovery process requires several steps to 360 find the PMTU of the full path, this could delay the connection by 361 many round-trip times. 363 Alternatively, the retransmission could be done in immediate response 364 to a notification that the Path MTU has changed, but only for the 365 specific connection specified by the Packet Too Big message. The 366 packet size used in the retransmission should, of course, be no 367 larger than the new PMTU. 369 Note: A packetization layer must not retransmit in response to 370 every Packet Too Big message, since a burst of several oversized 371 segments will give rise to several such messages and hence several 372 retransmissions of the same data. If the new estimated PMTU is 373 still wrong, the process repeats, and there is an exponential 374 growth in the number of superfluous segments sent! 376 This means that the TCP layer must be able to recognize when a 377 Packet Too Big notification actually decreases the PMTU that it 378 has already used to send a packet on the given connection, and 379 should ignore any other notifications. 381 Modern TCP implementations incorporate "congestion avoidance" and 382 "slow-start" algorithms to improve performance [CONG]. Unlike a 383 retransmission caused by a TCP retransmission timeout, a 384 retransmission caused by a Packet Too Big message should not change 385 the congestion window. It should, however, trigger the slow-start 386 mechanism (i.e., only one segment should be retransmitted until 387 acknowledgements begin to arrive again). 389 TCP performance can be reduced if the sender's maximum window size is 390 not an exact multiple of the segment size in use (this is not the 391 congestion window size, which is always a multiple of the segment 392 size). In many systems (such as those derived from 4.2BSD), the 393 segment size is often set to 1024 octets, and the maximum window size 394 (the "send space") is usually a multiple of 1024 octets, so the 395 proper relationship holds by default. If PMTU Discovery is used, 396 however, the segment size may not be a submultiple of the send space, 397 and it may change during a connection; this means that the TCP layer 398 may need to change the transmission window size when PMTU Discovery 399 changes the PMTU value. The maximum window size should be set to the 400 greatest multiple of the segment size that is less than or equal to 401 the sender's buffer space size. 403 4.5. Issues for other transport protocols 405 Some transport protocols (such as ISO TP4 [ISOTP]) are not allowed to 406 repacketize when doing a retransmission. That is, once an attempt is 407 made to transmit a segment of a certain size, the transport cannot 408 split the contents of the segment into smaller segments for 409 retransmission. In such a case, the original segment can be 410 fragmented by the IP layer during retransmission. Subsequent 411 segments, when transmitted for the first time, should be no larger 412 than allowed by the Path MTU. 414 The Sun Network File System (NFS) uses a Remote Procedure Call (RPC) 415 protocol [RPC] that, in many cases, sends payloads that must be 416 fragmented even for the first-hop link. This might improve 417 performance in certain cases, but it is known to cause reliability 418 and performance problems, especially when the client and server are 419 separated by routers. 421 It is recommended that NFS implementations use PMTU Discovery 422 whenever routers are involved. Most NFS implementations allow the 423 RPC datagram size to be changed at mount-time (indirectly, by 424 changing the effective file system block size), but might require 425 some modification to support changes later on. 427 Also, since a single NFS operation cannot be split across several UDP 428 datagrams, certain operations (primarily, those operating on file 429 names and directories) require a minimum payload size that if sent in 430 a single packet would exceed the PMTU. NFS implementations should 431 not reduce the payload size below this threshold, even if PMTU 432 Discovery suggests a lower value. (Of course, in this case the 433 payload will be fragmented by the IP layer.) 435 4.6. Management interface 437 It is suggested that an implementation provide a way for a system 438 utility program to: 440 - Specify that PMTU Discovery not be done on a given route. 442 - Change the PMTU value associated with a given route. 444 The former can be accomplished by associating a flag with the routing 445 entry; when a packet is sent via a route with this flag set, the IP 446 layer does not send packets larger than the IPv6 minimum link MTU. 448 These features might be used to work around an anomalous situation, 449 or by a routing protocol implementation that is able to obtain Path 450 MTU values. 452 The implementation should also provide a way to change the timeout 453 period for aging stale PMTU information. 455 5. Security considerations 457 This Path MTU Discovery mechanism makes possible two denial-of- 458 service attacks, both based on a malicious party sending false Packet 459 Too Big messages to a node. 461 In the first attack, the false message indicates a PMTU much smaller 462 than reality. This should not entirely stop data flow, since the 463 victim node should never set its PMTU estimate below the IPv6 minimum 464 link MTU. It will, however, result in suboptimal performance. 466 In the second attack, the false message indicates a PMTU larger than 467 reality. If believed, this could cause temporary blockage as the 468 victim sends packets that will be dropped by some router. Within one 469 round-trip time, the node would discover its mistake (receiving 470 Packet Too Big messages from that router), but frequent repetition of 471 this attack could cause lots of packets to be dropped. A node, 472 however, should never raise its estimate of the PMTU based on a 473 Packet Too Big message, so should not be vulnerable to this attack. 475 A malicious party could also cause problems if it could stop a victim 476 from receiving legitimate Packet Too Big messages, but in this case 477 there are simpler denial-of-service attacks available. 479 Acknowledgements 481 We would like to acknowledge the authors of and contributors to 482 [RFC-1191], from which the majority of this document was derived. 484 References 486 [CONG] Van Jacobson. Congestion Avoidance and Control. Proc. 487 SIGCOMM '88 Symposium on Communications Architectures and 488 Protocols, pages 314-329. Stanford, CA, August, 1988. 490 [FRAG] C. Kent and J. Mogul. Fragmentation Considered Harmful. 491 In Proc. SIGCOMM '87 Workshop on Frontiers in Computer 492 Communications Technology. August, 1987. 494 [ICMPv6] A. Conta and S. Deering, "Internet Control Message 495 Protocol (ICMPv6) for the Internet Protocol Version 6 496 (IPv6) Specification", June 1995 497 499 [IPv6-SPEC] S. Deering and R. Hinden, "Internet Protocol Version 6 500 [IPv6] Specification" Internet Draft, June 1995 501 503 [ISOTP] ISO. ISO Transport Protocol Specification: ISO DP 8073. 504 RFC 905, SRI Network Information Center, April, 1984. 506 [RFC-1191] J. Mogul and S. Deering, "Path MTU Discovery", 507 November 1990 509 [RPC] Sun Microsystems, Inc. RPC: Remote Procedure Call 510 Protocol. RFC 1057, SRI Network Information Center, 511 June, 1988. 513 Authors' Addresses 515 Jack McCann 516 Digital Equipment Corporation 517 110 Spitbrook Road, ZKO3-3/U14 518 Nashua, NH 03062 519 Phone: +1 603 881 2608 520 Fax: +1 603 881 0120 521 Email: mccann@zk3.dec.com 523 Stephen E. Deering 524 Xerox Palo Alto Research Center 525 3333 Coyote Hill Road 526 Palo Alto, CA 94304 527 Phone: +1 415 812 4839 528 Fax: +1 415 812 4471 529 Email: deering@parc.xerox.com 531 Expiration 533 May 6, 1996