rfc1207.FYI on Questions and Answers Answers to Commonly asked Experienced Internet User Questions
sap因rfc错误处理流程详解
sap因rfc错误处理流程详解SAP, as a leading enterprise resource planning (ERP) system, handles various processes and transactions within an organization. However, like any other complex system, it is not immune to errors. One such common error is the RFC (Remote Function Call) error, which occurs during the communication between SAP systems or between SAP and external systems. Understanding the RFC error handling process in SAP is crucial for efficient troubleshooting and system stability. SAP系统作为领先的企业资源规划（ERP）系统，负责处理组织内部的各种流程和交易。
然而，像任何其他复杂系统一样，它并非万无一失。
其中一种常见的错误是RFC（远程函数调用）错误，这种错误发生在SAP系统之间或SAP与外部系统之间的通信过程中。
了解SAP中的RFC错误处理流程对于有效的故障排除和系统稳定性至关重要。
When an RFC error occurs, SAP triggers a series of steps to identify and resolve the issue. Firstly, the system logs the error details, including the error code, description, and any relevant data. This information is crucial for diagnosing the problem. The SAP administrator or support team can then access these logs to analyze the error.当RFC错误发生时，SAP会触发一系列步骤来识别和解决问题。
rfc1275.Replication Requirements to provide an Internet Directory using X.500
Network Working Group S.E. Hardcastle-Kille Requests for Comments 1275 University College London November 1991 Replication Requirements to provide an Internet Directory using X.500Status of this MemoThis memo provides information for the Internet community. Itdoes not specify an Internet standard. Distribution of this memo is unlimited.AbstractThis RFCconsiders certain deficiencies of the 1988 X.500standard, which need to be addressed before an effective openInternet Directory can be established using these protocols andservices [CCI88]. The only areas considered are primaryproblems, to which solutions must be found before a pilot can bedeployed. This RFCconcerns itself with deficiencies which canonly be addressed by use of additional protocol or procedures for distributed operation.1 Distributed Operation ExtensionsThe Internet Directory will operate DSAs over TCP/IP using RFC 1006 [RC87], and DSAs over the an ISO Network Service. Distributedoperation procedures should not require full connectivity.2 Knowledge ReplicationKnowledge information is critical to resolution of names, and performing searches. Knowledge information high up the tree needs to be widely available. Consider resolving a name below ‘‘Country=US’’. To do this, a DSA needs to have full knowledge at this point. Many DSAs need to be able to do this, in order to give reasonable response and availability. It would be an unacceptable bottleneck to force such resolution to a single or small number of DSAs. To replicatethis knowledge widely, a systematic approach to replication is needed.3 Data ReplicationSearches are often made at the root and country level, and this is a vital service (e.g., an approximate match of an organisation name). Data needs to be collected in such a way that this sort of searchingis reasonably efficient. The usual X.500 approach of subordinate references militates against this. At a node in the DIT, subordinate references to the entries below are held. These entries will be in many DSAs, each of which needs to be accessed in order to perform the single level search. It is suggested that replication of data is necessary to achieve this.The major requirement for this replication is high up the DIT, where information must be replicated between different implementations. At lower levels of the DIT, it is reasonable for DSAs to be of the same implementation and to use implementation specific techniques in order to achieve performance and availability.4 Alternate DSAsWhen a DSA Referral is returned, only the master DSA is indicated.This will lead to a single point of failure. It seems important to allow for additional references to slave copies, in order to get Hardcastle-Kille Page 1better availability. This needs to be solved in conjunction with the problem described in the previous section.5 Guidelines for use of ReplicationTo be effective, the replication specification needs to provide guidelines for deployment in the pilot, in order to meet the desired service criteria.6 Some scaling targetsMost techniques for replication have scaling limits. It is important that mechanisms used do not stress the limits of the mechanism. The order of magnitude envisioned in the pilot is 100 000 non-leaf entries and several million leaf entries.References[CCI88] The Directory --- overview of concepts, models and services,December 1988. CCITT X.500 Series Recommendations.[RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport Serviceson top of the TCP. Request for Comments 1006, NorthropCorporation Technology Center, May 1987.7 Security ConsiderationsSecurity considerations are not discussed in this memo.8 Author’s AddressSteve Hardcastle-KilleDepartment of Computer ScienceUniversity College LondonGower StreetWC1E 6BTEnglandHardcastle-Kille Page 2Phone: +44-71-380-7294EMail: S.Kille@Hardcastle-Kille Page 3。
RFC1242
Internet RFC/STD/FYI/BCP ArchivesRFC1242[ Index | Search | What's New | Comments | Help ]Network Working Group S. Bradner, Editor Request for Comments: 1242 Harvard University July 1991Benchmarking Terminology for Network Interconnection DevicesStatus of this MemoThis memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo isunlimited.AbstractThis memo discusses and defines a number of terms that are used indescribing performance benchmarking tests and the results of suchtests. The terms defined in this memo will be used in additionalmemos to define specific benchmarking tests and the suggested format to be used in reporting the results of each of the tests. This memo is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF).1. IntroductionVendors often engage in "specsmanship" in an attempt to give theirproducts a better position in the marketplace. This usually involves much "smoke & mirrors" used to confuse the user. This memo andfollow-up memos attempt to define a specific set of terminology and tests that vendors can use to measure and report the performancecharacteristics of network devices. This will provide the usercomparable data from different vendors with which to evaluate these devices.2. Definition formatTerm to be defined. (e.g., Latency)Definition:The specific definition for the term.Discussion:A brief discussion about the term, it's applicationand any restrictions on measurement procedures.Measurement units:The units used to report measurements of thisterm, if applicable.Issues:List of issues or conditions that effect this term.See Also:List of other terms that are relevant to the discussion of this term.3. Term definitions3.1 Back-to-backDefinition:Fixed length frames presented at a rate such that there is the minimum legal separation for a given mediumbetween frames over a short to medium period of time,starting from an idle state.Discussion:A growing number of devices on a network can producebursts of back-to-back frames. Remote disk serversusing protocols like NFS, remote disk backup systemslike rdump, and remote tape access systems can beconfigured such that a single request can result ina block of data being returned of as much as 64K octets. Over networks like ethernet with a relatively small MTU this results in many fragments to be transmitted. Since fragment reassembly will only be attempted if allfragments have been received, the loss of even onefragment because of the failure of some intermediatenetwork device to process enough continuous frames can cause an endless loop as the sender repetitivelyattempts to send its large data block.With the increasing size of the Internet, routingupdates can span many frames, with modern routers able to transmit very quickly. Missing frames of routinginformation can produce false indications ofunreachability. Tests of this parameter are intendedto determine the extent of data buffering in thedevice.Measurement units:Number of N-octet frames in burst.Issues:See Also:3.2 BridgeDefinition:A system which forwards data frames based on information in the data link layer.Discussion:Measurement units:n/aIssues:See Also:bridge/router (3.3)router (3.15)3.3 bridge/routerDefinition:A bridge/router is a network device that can selectively function as a router and/or a bridge based on theprotocol of a specific frame.Discussion:Measurement units:n/aIssues:See Also:bridge (3.2)router (3.15)3.4 Constant LoadDefinition:Fixed length frames at a fixed interval time.Discussion:Although it is rare, to say the least, to encountera steady state load on a network device in the realworld, measurement of steady state performance maybe useful in evaluating competing devices. Theframe size is specified and constant. All deviceparameters are constant. When there is a checksumin the frame, it must be verified.Measurement units:n/aIssues:unidirectional vs. bidirectionalSee Also:3.5 Data link frame sizeDefinition:The number of octets in the frame from the first octet following the preamble to the end of the FCS, ifpresent, or to the last octet of the data if thereis no FCS.Discussion:There is much confusion in reporting the framesizes used in testing network devices or networkmeasurement. Some authors include the checksum,some do not. This is a specific definition for usein this and subsequent memos.Measurement units:octetsIssues:See Also:3.6 Frame Loss RateDefinition:Percentage of frames that should have been forwardedby a network device under steady state (constant)load that were not forwarded due to lack ofresources.Discussion:This measurement can be used in reporting theperformance of a network device in an overloadedstate. This can be a useful indication of how adevice would perform under pathological networkconditions such as broadcast storms.Measurement units:Percentage of N-octet offered frames that are dropped. To be reported as a graph of offered load vs frame loss.Issues:See Also:overhead behavior (3.11)policy based filtering (3.13)MTU mismatch behavior (3.10)3.7 Inter Frame GapDefinition:The delay from the end of a data link frame as defined in section 3.5, to the start of the preamble of thenext data link frame.Discussion:There is much confusion in reporting the betweenframe time used in testing network devices. Thisis a specific definition for use in this and subsequent memos.Measurement units:Time with fine enough units to distinguish between2 events.Issues:Link data rate.See Also:3.8 LatencyDefinition:For store and forward devices:The time interval starting when the last bit of theinput frame reaches the input port and ending whenthe first bit of the output frame is seen on theoutput port.For bit forwarding devices:The time interval starting when the end of the firstbit of the input frame reaches the input port andending when the start of the first bit of the outputframe is seen on the output port.Discussion:Variability of latency can be a problem.Some protocols are timing dependent (e.g., LAT and IPX). Future applications are likely to be sensitive tonetwork latency. Increased device delay can reducethe useful diameter of net. It is desired toeliminate the effect of the data rate on the latencymeasurement. This measurement should only reflect the actual within device latency. Measurements should betaken for a spectrum of frame sizes without changingthe device setup.Ideally, the measurements for all devices would be fromthe first actual bit of the frame after the preamble. Theoretically a vendor could design a device thatnormally would be considered a store and forwarddevice, a bridge for example, that begins transmitting a frame before it is fully received. This type ofdevice is known as a "cut through" device. Theassumption is that the device would somehow invalidate the partially transmitted frame if in receiving theremainder of the input frame, something came up that the frame or this specific forwarding of it was inerror. For example, a bad checksum. In this case,the device would still be considered a store andforward device and the latency would still befrom last bit in to first bit out, even though thevalue would be negative. The intent is to treatthe device as a unit without regard to the internalstructure.Measurement units:Time with fine enough units to distinguish between2 events.Issues:See Also:link speed mismatch (3.9)constant load (3.4)back-to-back (3.1)policy based filtering (3.13)single frame behavior (3.16)3.9 Link Speed MismatchDefinition:Speed mismatch between input and output data rates.Discussion:This does not refer to frame rate per se, it refers to the actual data rate of the data path. For example,an Ethernet on one side and a 56KB serial link on the other. This is has also been referred to as the "fire hose effect". Networks that make use of serial links between local high speed networks will usually havelink speed mismatch at each end of the serial links.Measurement units:Ratio of input and output data rates.Issues:See Also:constant load (3.4)back-to-back (3.1)3.10 MTU-mismatch behaviorDefinition:The network MTU (Maximum Transmission Unit) of theoutput network is smaller than the MTU of the inputnetwork, this results in fragmentation.Discussion:The performance of network devices can be significantly affected by having to fragment frames.Measurement units:Description of behavior.Issues:See Also:3.11 Overhead behaviorDefinition:Processing done other than that for normal data frames.Discussion:Network devices perform many functions in additionto forwarding frames. These tasks range from internal hardware testing to the processing of routinginformation and responding to network managementrequests. It is useful to know what the effect ofthese sorts of tasks is on the device performance.An example would be if a router were to suspendforwarding or accepting frames during the processingof large routing update for a complex protocol likeOSPF. It would be good to know of this sort ofbehavior.Measurement units:Any quantitative understanding of this behavior is by the determination of its effect on other measurements.Issues:bridging and routing protocolscontrol processingicmpip options processingfragmentationerror processingevent logging/statistics collectionarpSee Also:policy based filtering (3.13)3.12 Overloaded behaviorDefinition:When demand exceeds available system resources.Discussion:Devices in an overloaded state will lose frames. The device might lose frames that contain routing orconfiguration information. An overloaded state isassumed when there is any frame loss.Measurement units:Description of behavior of device in any overloadedstates for both input and output overload conditions.Issues:How well does the device recover from overloaded state? How does source quench production effect device?What does device do when its resources are exhausted? What is response to system management in overloadedstate?See Also:3.13 Policy based filteringDefinition:Filtering is the process of discarding receivedframes by administrative decision where normaloperation would be to forward them.Discussion:Many network devices have the ability to beconfigured to discard frames based on a numberof criteria. These criteria can range from simplesource or destination addresses to examiningspecific fields in the data frame itself.Configuring many network devices to performfiltering operations impacts the throughputof the device.Measurement units:n/aIssues:flexibility of filter optionsnumber of filter conditionsSee Also:3.14 Restart behaviorDefinition:Reinitialization of system causing data loss.Discussion:During a period of time after a power up orreset, network devices do not accept and forwardframes. The duration of this period of unavailabilitycan be useful in evaluating devices. In addition,some network devices require some form of resetwhen specific setup variables are modified. If thereset period were long it might discourage networkmanagers from modifying these variables on productionnetworks.Measurement units:Description of device behavior under various restartconditions.Issues:Types:power onreload software imageflush port, reset buffersrestart current code image, without reconfurationUnder what conditions is a restart required?Does the device know when restart needed (i.e., hungstate timeout)?Does the device recognize condition of too frequentauto-restart?Does the device run diagnostics on all or some resets?How may restart be initiated?physical interventionremote via terminal line or login over networkSee Also:3.15 RouterDefinition:A system which forwards data frames based oninformation in the network layer.Discussion:This implies "running" the network level protocolrouting algorithm and performing whatever actionsthat the protocol requires. For example, decrementingthe TTL field in the TCP/IP header.Measurement units:n/aIssues:See Also:bridge (3.2)bridge/router (3.3)3.16 Single frame behaviorDefinition:One frame received on the input to a device.Discussion:A data "stream" consisting of a single frame canrequire a network device to do a lot of processing.Figuring routes, performing ARPs, checkingpermissions etc., in general, setting up cache entries. Devices will often take much more time to process asingle frame presented in isolation than it would ifthe same frame were part of a steady stream. Thereis a worry that some devices would even discard a single frame as part of the cache setup procedure under theassumption that the frame is only the first of many.Measurement units:Description of the behavior of the device.Issues:See Also:policy based filtering (3.13)3.17 ThroughputDefinition:The maximum rate at which none of the offered framesare dropped by the device.Discussion:The throughput figure allows vendors to report asingle value which has proven to have use in themarketplace. Since even the loss of one frame in adata stream can cause significant delays whilewaiting for the higher level protocols to time out,it is useful to know the actual maximum datarate that the device can support. Measurements should be taken over a assortment of frame sizes. Separatemeasurements for routed and bridged data in thosedevices that can support both. If there is a checksum in the received frame, full checksum processing mustbe done.Measurement units:N-octet input frames per secondinput bits per secondIssues:single path vs. aggregateloadunidirectional vs bidirectionalchecksum processing required on some protocolsSee Also:frame loss rate (3.6)constant load (3.4)back-to-back (3.1)4. AcknowledgementsThis memo is a product of the IETF BMWG working group:Chet Birger, Coral NetworksScott Bradner, Harvard University (chair)Steve Butterfield, independant consultantFrank Chui, TRWPhill Gross, CNRIStev Knowles, FTP Software, Inc.Mat Lew, TRWGary Malkin, FTP Software, Inc.K.K. Ramakrishnan, Digital Equipment Corp.Mick Scully, Ungerman BassWilliam M. Seifert, Wellfleet Communications Corp.John Shriver, Proteon, Inc.Dick Sterry, MicrocomGeof Stone, Network Systems Corp.Geoff Thompson, SynOpticsMary Youssef, IBMSecurity ConsiderationsSecurity issues are not discussed in this memo.Author's AddressScott BradnerHarvard UniversityWilliam James Hall 123233 Kirkland StreetCambridge, MA 02138Phone: (617) 495-3864EMail: SOB@Or, send comments to: bmwg@.[ Index | Search | What's New | Comments | Help ] Comments/Questions about this archive ? Send mail to rfc-admin@。
imap rfc标准
Internet Message Access Protocol (IMAP) is an email retrieval protocol. It stores email messages on a mail server and enables the recipient to view and manipulate them as though they were stored locally on their device. IMAP was developed in the late 1980s and has since become one of the most widely used email retrieval protocols.The IMAP standard is defined in RFC 3501, which was published in 2003. This document provides a detailed description of the protocol's functionality, including its data formats, commands, and responses. The standard specifies how IMAP clients and servers should communicate with each other to enable the retrieval and manipulation of email messages.One of the key features of IMAP is its support for multiple clients accessing the same mailbox simultaneously. This is achieved through the use of a "shared" storage model, where all clients see the same set of messages and folders stored on the server. This allows users to access their email from different devices without having to worry about synchronizing their messages manually.Another important aspect of IMAP is its support for message organization and management. Clients can create, delete, and rename folders, as well as move messages between folders. They can also search for specific messages based on various criteria, such as sender, subject, or date.IMAP also provides a range of features for managing individual messages. Clients can mark messages as read or unread, flag them for follow-up, and even move them to a specific folder. They can also reply to messages, forward them to others, and generate replies or forwards with attachments.Overall, the IMAP standard provides a powerful and flexible framework for managing email messages. Its support for shared storage, message organization, and advanced message management features make it a popular choice for both personal and business email users.。
DHCP的RFC文档-RFC2131
Network Working Group R. DromsRequest for Comments: 2131 Bucknell UniversityObsoletes: 1541 March 1997Category: Standards TrackDynamic Host Configuration ProtocolStatus of this memoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.AbstractThe Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding thecapability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior of BOOTP relay agents [7, 21], and DHCP participants can interoperate with BOOTP participants [9].Table of Contents1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 3 1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Problem definition and issues . . . . . . . . . . . . . . . . 4 1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 61.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 62. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8 2.1 Configuration parameters repository . . . . . . . . . . . . . 112.2 Dynamic allocation of network addresses . . . . . . . . . . .123. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13 3.1 Client-server interaction - allocating a network address. . . 13 3.2 Client-server interaction - reusing a previously allocatednetwork address . . . . . . . . . . . . . . . . . . . . . . . 173.3 Interpretation and representation of time values. . . . . . . 20 3.4 Obtaining parameters with externally configured networkaddress . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21 3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 223.7 When clients should use DHCP. . . . . . . . . . . . . . . . .224. Specification of the DHCP client-server protocol. . . . . . . 22Droms Standards Track [Page 1]RFC 2131 Dynamic Host Configuration Protocol March 19974.1 Constructing and sending DHCP messages. . . . . . . . . . . .22 4.2 DHCP server administrative controls . . . . . . . . . . . . . 25 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 264.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . .345. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .426. References . . . . . . . . . . . . . . . . . . . . . . . . . .427. Security Considerations. . . . . . . . . . . . . . . . . . . .438. Author's Address . . . . . . . . . . . . . . . . . . . . . . .44A. Host Configuration Parameters . . . . . . . . . . . . . . . .45 List of Figures1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 92. Format of the 'flags' field. . . . . . . . . . . . . . . . . .113. Timeline diagram of messages exchanged between DHCP client and servers when allocating a new network address. . . . . . . . . 154. Timeline diagram of messages exchanged between DHCP client and servers when reusing a previously allocated network address. . 185. State-transition diagram for DHCP clients. . . . . . . . . . .34 List of Tables1. Description of fields in a DHCP message. . . . . . . . . . . .102. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . .143. Fields and options used by DHCP servers. . . . . . . . . . . .284. Client messages from various states. . . . . . . . . . . . . .335. Fields and options used by DHCP clients. . . . . . . . . . . .37 1. IntroductionThe Dynamic Host Configuration Protocol (DHCP) provides configuration parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from aDHCP server to a host and a mechanism for allocation of networkaddresses to hosts.DHCP is built on a client-server model, where designated DHCP server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts. Throughout the remainder of this document, the term "server" refers to a host providinginitialization parameters through DHCP, and the term "client" refers to a hostrequesting initialization parameters from a DHCP server.A host should not act as a DHCP server unless explicitly configured to do so by a system administrator. The diversity of hardware and protocol implementations in the Internet would preclude reliable operation if random hosts were allowed to respond to DHCP requests. For example, IP requires the setting of many parameters within the protocol implementation software. Because IP can be used on many dissimilar kinds of network hardware, values for those parameters cannot be guessed or assumed to have correct defaults. Also,distributed address allocation schemes depend on a polling/defenseDroms Standards Track [Page 2]RFC 2131 Dynamic Host Configuration Protocol March 1997mechanism for discovery of addresses that are already in use. IP hosts may not always be able to defend their network addresses, so that such a distributed address allocation scheme cannot beguaranteed to avoid allocation of duplicate network addresses.DHCP supports three mechanisms for IP address allocation. In"automatic allocation", DHCP assigns a permanent IP address to aclient. In "dynamic allocation", DHCP assigns an IP address to a client for a limited period of time (or until the client explicitly relinquishes the address). In "manual allocation", a client's IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client. A particular network will use one or more of these mechanisms, depending on the policies of the network administrator.Dynamic allocation is the only one of the three mechanisms thatallows automatic reuse of an address that is no longer needed by the client to which it was assigned. Thus, dynamic allocation isparticularly useful for assigning an address to a client that will be connected to the network only temporarily or for sharing a limited pool of IP addresses among a group of clients that do not needpermanent IP addresses. Dynamic allocation may also be a good choice for assigning an IP address to a new client being permanentlyconnected to a network where IP addresses are sufficiently scarce that it is important to reclaim them when old clients are retired. Manual allocation allows DHCP to be used to eliminate the error-prone process of manually configuring hosts with IP addresses inenvironments where (for whatever reasons) it is desirable to manage IP address assignment outside of the DHCP mechanisms.The format of DHCP messages is based on the format of BOOTP messages, to capture the BOOTP relay agent behavior described as part of the BOOTP specification [7, 21] and to allow interoperability ofexisting BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates the necessity of having a DHCP server on each physical networksegment.1.1 Changes to RFC 1541This document updates the DHCP protocol specification that appears in RFC1541. A new DHCP message type, DHCPINFORM, has been added; see section 3.4, 4.3 and 4.4 for details. The classing mechanism for identifying DHCP clients to DHCP servers has been extended to include "vendor" classes as defined in sections 4.2 and 4.3. The minimum lease time restriction has been removed. Finally, many editorial changes have been made to clarify the text as a result of experience gained in DHCP interoperability tests.Droms Standards Track [Page 3]RFC 2131 Dynamic Host Configuration Protocol March 19971.2 Related WorkThere are several Internet protocols and related mechanisms that address some parts of the dynamic host configuration problem. The Reverse Address Resolution Protocol (RARP) [10] (through theextensions defined in the Dynamic RARP (DRARP) [5]) explicitlyaddresses the problem of network address discovery, and includes an automatic IP address assignment mechanism. The Trivial File Transfer Protocol (TFTP) [20] provides for transport of a boot image from a boot server. The Internet Control Message Protocol (ICMP) [16]provides for informing hosts of additional routers via "ICMPredirect" messages. ICMP also can provide subnet mask information through the "ICMP mask request" message and other information through the (obsolete) "ICMP information request" message. Hosts can locate routers through the ICMP router discovery mechanism [8].BOOTP is a transport mechanism for a collection of configuration information. BOOTP is also extensible, and official extensions [17] have been defined for several configuration parameters. Morgan has proposed extensions to BOOTP for dynamic IP address assignment [15]. The Network Information Protocol (NIP), used by the Athena project at MIT, is a distributed mechanism for dynamic IP address assignment [19]. The Resource Location Protocol RLP [1] provides for location of higher level services. Sun Microsystems diskless workstations use a boot procedure that employs RARP, TFTP and an RPC mechanism called "bootparams" to deliver configuration information and operatingsystem code to diskless hosts. (Sun Microsystems, Sun Workstation and SunOS are trademarks of Sun Microsystems, Inc.) Some Sunnetworks also use DRARP and an auto-installation mechanism toautomate the configuration of new hosts in an existing network.In other related work, the path minimum transmission unit (MTU)discovery algorithm can determine the MTU of an arbitrary internet path [14]. The Address Resolution Protocol (ARP) has been proposed as a transport protocol for resource location and selection [6]. Finally, the Host Requirements RFCs [3, 4] mention specificrequirements for host reconfiguration and suggest a scenario for继续阅读。
rfc1462.FYI on What is the Internet
Network Working Group E. Krol Request for Comments: 1462 University of Illinois FYI: 20 E. HoffmanMerit Network, Inc.May 1993FYI on "What is the Internet?"Status of this MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard. Distribution of this memo isunlimited.AbstractThis FYI RFC answers the question, "What is the Internet?" and isproduced by the User Services Working Group of the InternetEngineering Task Force (IETF). Containing a modified chapter from Ed Krol’s 1992 book, "The Whole Internet User’s Guide and Catalog," the paper covers the Internet’s definition, history, administration,protocols, financing, and current issues such as growth,commercialization, and privatization.IntroductionA commonly asked question is "What is the Internet?" The reason such a question gets asked so often is because there’s no agreed uponanswer that neatly sums up the Internet. The Internet can be thought about in relation to its common protocols, as a physical collectionof routers and circuits, as a set of shared resources, or even as an attitude about interconnecting and intercommunication. Some commondefinitions given in the past include:* a network of networks based on the TCP/IP protocols,* a community of people who use and develop those networks,* a collection of resources that can be reached from thosenetworks.Today’s Internet is a global resource connecting millions of usersthat began as an experiment over 20 years ago by the U.S. Department of Defense. While the networks that make up the Internet are based on a standard set of protocols (a mutually agreed upon method ofcommunication between parties), the Internet also has gateways tonetworks and services that are based on other protocols.Krol & Hoffman [Page 1]To help answer the question more completely, the rest of this papercontains an updated second chapter from "The Whole Internet User’sGuide and Catalog" by Ed Krol (1992) that gives a more thoroughexplanation. (The excerpt is published through the graciouspermission of the publisher, O’Reilly & Associates, Inc.)The Internet (excerpt from "The Whole Internet User’s Guide and Catalog")The Internet was born about 20 years ago, trying to connect together a U.S. Defense Department network called the ARPAnet and variousother radio and satellite networks. The ARPAnet was an experimentalnetwork designed to support military research--in particular,research about how to build networks that could withstand partialoutages (like bomb attacks) and still function. (Think about thiswhen I describe how the network works; it may give you some insightinto the design of the Internet.) In the ARPAnet model, communication always occurs between a source and a destination computer. Thenetwork itself is assumed to be unreliable; any portion of thenetwork could disappear at any moment (pick your favoritecatastrophe--these days backhoes cutting cables are more of a threat than bombs). It was designed to require the minimum of informationfrom the computer clients. To send a message on the network, acomputer only had to put its data in an envelope, called an Internet Protocol (IP) packet, and "address" the packets correctly. Thecommunicating computers--not the network itself--were also given the responsibility to ensure that the communication was accomplished. The philosophy was that every computer on the network could talk, as apeer, with any other computer.These decisions may sound odd, like the assumption of an "unreliable" network, but history has proven that most of them were reasonablycorrect. Although the Organization for International Standardization (ISO) was spending years designing the ultimate standard for computer networking, people could not wait. Internet developers in the US, UK and Scandinavia, responding to market pressures, began to put theirIP software on every conceivable type of computer. It became the only practical method for computers from different manufacturers tocommunicate. This was attractive to the government and universities, which didn’t have policies saying that all computers must be boughtfrom the same vendor. Everyone bought whichever computer they liked, and expected the computers to work together over the network.At about the same time as the Internet was coming into being,Ethernet local area networks ("LANs") were developed. This technology matured quietly, until desktop workstations became available around1983. Most of these workstations came with Berkeley UNIX, whichincluded IP networking software. This created a new demand: rather Krol & Hoffman [Page 2]than connecting to a single large timesharing computer per site,organizations wanted to connect the ARPAnet to their entire localnetwork. This would allow all the computers on that LAN to accessARPAnet facilities. About the same time, other organizations started building their own networks using the same communications protocolsas the ARPAnet: namely, IP and its relatives. It became obvious that if these networks could talk together, users on one network couldcommunicate with those on another; everyone would benefit.One of the most important of these newer networks was the NSFNET,commissioned by the National Science Foundation (NSF), an agency ofthe U.S. government. In the late 80’s the NSF created fivesupercomputer centers. Up to this point, the world’s fastestcomputers had only been available to weapons developers and a fewresearchers from very large corporations. By creating supercomputercenters, the NSF was making these resources available for anyscholarly research. Only five centers were created because they were so expensive--so they had to be shared. This created a communications problem: they needed a way to connect their centers together and toallow the clients of these centers to access them. At first, the NSF tried to use the ARPAnet for communications, but this strategy failed because of bureaucracy and staffing problems.In response, NSF decided to build its own network, based on theARPAnet’s IP technology. It connected the centers with 56,000 bit per second (56k bps) telephone lines. (This is roughly the ability totransfer two full typewritten pages per second. That’s slow bymodern standards, but was reasonably fast in the mid 80’s.) It wasobvious, however, that if they tried to connect every universitydirectly to a supercomputing center, they would go broke. You pay for these telephone lines by the mile. One line per campus with asupercomputing center at the hub, like spokes on a bike wheel, addsup to lots of miles of phone lines. Therefore, they decided to create regional networks. In each area of the country, schools would beconnected to their nearest neighbor. Each chain was connected to asupercomputer center at one point and the centers were connectedtogether. With this configuration, any computer could eventuallycommunicate with any other by forwarding the conversation through its neighbors.This solution was successful--and, like any successful solution, atime came when it no longer worked. Sharing supercomputers alsoallowed the connected sites to share a lot of other things notrelated to the centers. Suddenly these schools had a world of dataand collaborators at their fingertips. The network’s trafficincreased until, eventually, the computers controlling the networkand the telephone lines connecting them were overloaded. In 1987, acontract to manage and upgrade the network was awarded to MeritKrol & Hoffman [Page 3]Network Inc., which ran Michigan’s educational network, inpartnership with IBM and MCI. The old network was replaced withfaster telephone lines (by a factor of 20), with faster computers to control it.The process of running out of horsepower and getting bigger enginesand better roads continues to this day. Unlike changes to the highway system, however, most of these changes aren’t noticed by the peopletrying to use the Internet to do real work. You won’t go to youroffice, log in to your computer, and find a message saying that theInternet will be inaccessible for the next six months because ofimprovements. Perhaps even more important: the process of running out of capacity and improving the network has created a technology that’s extremely mature and practical. The ideas have been tested; problems have appeared, and problems have been solved.For our purposes, the most important aspect of the NSF’s networkingeffort is that it allowed everyone to access the network. Up to that point, Internet access had been available only to researchers incomputer science, government employees, and government contractors.The NSF promoted universal educational access by funding campusconnections only if the campus had a plan to spread the accessaround. So everyone attending a four year college could become anInternet user.The demand keeps growing. Now that most four-year colleges areconnected, people are trying to get secondary and primary schoolsconnected. People who have graduated from college know what theInternet is good for, and talk their employers into connectingcorporations. All this activity points to continued growth,networking problems to solve, evolving technologies, and job security for networkers.What Makes Up the Internet?What comprises the Internet is a difficult question; the answerchanges over time. Five years ago the answer would have been easy:"All the networks, using the IP protocol, which cooperate to form aseamless network for their collective users." This would includevarious federal networks, a set of regional networks, campusnetworks, and some foreign networks.More recently, some non-IP-based networks saw that the Internet wasgood. They wanted to provide its services to their clientele. So they developed methods of connecting these "strange" networks (e.g.,Bitnet, DECnets, etc.) to the Internet. At first these connections,called "gateways", merely served to transfer electronic mail between the two networks. Some, however, have grown to translate otherKrol & Hoffman [Page 4]services between the networks as well. Are they part of the Internet? Maybe yes and maybe no. It depends on whether, in their hearts, they want to be. If this sounds strange, read on--it gets stranger.Who Governs the Internet?In many ways the Internet is like a church: it has its council ofelders, every member has an opinion about how things should work, and you can either take part or not. It’s your choice. The Internet hasno president, chief operating officer, or Pope. The constituentnetworks may have presidents and CEO’s, but that’s a different issue; there’s no single authority figure for the Internet as a whole.The ultimate authority for where the Internet is going rests with the Internet Society, or ISOC. ISOC is a voluntary membershiporganization whose purpose is to promote global information exchange through Internet technology. (If you’d like more information, or if you would like to join, contact information is provided in the "ForMore Information" section, near the end of this document.) Itappoints a council of elders, which has responsibility for thetechnical management and direction of the Internet.The council of elders is a group of invited volunteers called theInternet Architecture Board, or the IAB. The IAB meets regularly to"bless" standards and allocate resources, like addresses. TheInternet works because there are standard ways for computers andsoftware applications to talk to each other. This allows computersfrom different vendors to communicate without problems. It’s not anIBM-only or Sun-only or Macintosh-only network. The IAB isresponsible for these standards; it decides when a standard isnecessary, and what the standard should be. When a standard isrequired, it considers the problem, adopts a standard, and announces it via the network. (You were expecting stone tablets?) The IAB also keeps track of various numbers (and other things) that must remainunique. For example, each computer on the Internet has a unique 32-bit address; no other computer has the same address. How does thisaddress get assigned? The IAB worries about these kinds of problems. It doesn’t actually assign the addresses, but it makes the rulesabout how to assign addresses.As in a church, everyone has opinions about how things ought to run. Internet users express their opinions through meetings of theInternet Engineering Task Force (IETF). The IETF is another volunteer organization; it meets regularly to discuss operational and near-term technical problems of the Internet. When it considers a problemimportant enough to merit concern, the IETF sets up a "working group" for further investigation. (In practice, "important enough" usuallymeans that there are enough people to volunteer for the workingKrol & Hoffman [Page 5]group.) Anyone can attend IETF meetings and be on working groups; the important thing is that they work. Working groups have many different functions, ranging from producing documentation, to deciding hownetworks should cooperate when problems occur, to changing themeaning of the bits in some kind of packet. A working group usuallyproduces a report. Depending on the kind of recommendation, it could just be documentation and made available to anyone wanting it, itcould be accepted voluntarily as a good idea which people follow, or it could be sent to the IAB to be declared a standard.If you go to a church and accept its teachings and philosophy, youare accepted by it, and receive the benefits. If you don’t like it,you can leave. The church is still there, and you get none of thebenefits. Such is the Internet. If a network accepts the teachings of the Internet, is connected to it, and considers itself part of it,then it is part of the Internet. It will find things it doesn’t like and can address those concerns through the IETF. Some concerns may be considered valid and the Internet may change accordingly. Some ofthe changes may run counter to the religion, and be rejected. If the network does something that causes damage to the Internet, it couldbe excommunicated until it mends its evil ways.Who Pays for It?The old rule for when things are confusing is "follow the money."Well, this won’t help you to understand the Internet. No one pays for "it"; there is no Internet, Inc. that collects fees from all Internet networks or users. Instead, everyone pays for their part. The NSFpays for NSFNET. NASA pays for the NASA Science Internet. Networksget together and decide how to connect themselves together and fundthese interconnections. A college or corporation pays for theirconnection to some regional network, which in turn pays a nationalprovider for its access.What Does This Mean for Me?The concept that the Internet is not a network, but a collection ofnetworks, means little to the end user. You want to do somethinguseful: run a program, or access some unique data. You shouldn’t have to worry about how it’s all stuck together. Consider the telephonesystem--it’s an internet, too. Pacific Bell, AT&T, MCI, BritishTelephony, Telefonos de Mexico, and so on, are all separatecorporations that run pieces of the telephone system. They worryabout how to make it all work together; all you have to do is dial.If you ignore cost and commercials, you shouldn’t care if you aredealing with MCI, AT&T, or Sprint. Dial the number and it works.Krol & Hoffman [Page 6]You only care who carries your calls when a problem occurs. Ifsomething goes out of service, only one of those companies can fixit. They talk to each other about problems, but each phone carrier is responsible for fixing problems on its own part of the system. Thesame is true on the Internet. Each network has its own networkoperations center (NOC). The operation centers talk to each other and know how to resolve problems. Your site has a contract with one ofthe Internet’s constituent networks, and its job is to keep your site happy. So if something goes wrong, they are the ones to gripe at. If it’s not their problem, they’ll pass it along.What Does the Future Hold?Finally, a question I can answer. It’s not that I have a crystal ball (if I did I’d spend my time on Wall Street instead of writing abook). Rather, these are the things that the IAB and the IETF discuss at their meetings. Most people don’t care about the long discussions; they only want to know how they’ll be affected. So, here arehighlights of the networking future.New Standard ProtocolsWhen I was talking about how the Internet started, I mentioned theInternational Standards Organization (ISO) and their set of protocol standards. Well, they finally finished designing it. Now it is aninternational standard, typically referred to as the ISO/OSI (OpenSystems Interconnect) protocol suite. Many of the Internet’scomponent networks allow use of OSI today. There isn’t much demand,yet. The U.S. government has taken a position that governmentcomputers should be able to speak these protocols. Many have thesoftware, but few are using it now.It’s really unclear how much demand there will be for OSI,notwithstanding the government backing. Many people feel that thecurrent approach isn’t broke, so why fix it? They are just becomingcomfortable with what they have, why should they have to learn a new set of commands and terminology just because it is the standard?Currently there are no real advantages to moving to OSI. It is morecomplex and less mature than IP, and hence doesn’t work asefficiently. OSI does offer hope of some additional features, but it also suffers from some of the same problems which will plague IP asthe network gets much bigger and faster. It’s clear that some siteswill convert to the OSI protocols over the next few years. Thequestion is: how many?Krol & Hoffman [Page 7]International ConnectionsThe Internet has been an international network for a long time, butit only extended to the United States’ allies and overseas militarybases. Now, with the less paranoid world environment, the Internet is spreading everywhere. It’s currently in over 50 countries, and thenumber is rapidly increasing. Eastern European countries longing for western scientific ties have wanted to participate for a long time,but were excluded by government regulation. This ban has beenrelaxed. Third world countries that formerly didn’t have the means to participate now view the Internet as a way to raise their educationand technology levels.In Europe, the development of the Internet used to be hampered bynational policies mandating OSI protocols, regarding IP as a cultural threat akin to EuroDisney. These policies prevented development oflarge scale Internet infrastructures except for the Scandinaviancountries which embraced the Internet protocols long ago and arealready well-connected. In 1989, RIPE (Reseaux IP Europeens) begancoordinating the operation of the Internet in Europe and presentlyabout 25% of all hosts connected to the Internet are located inEurope.At present, the Internet’s international expansion is hampered by the lack of a good supporting infrastructure, namely a decent telephonesystem. In both Eastern Europe and the third world, a state-of-the-art phone system is nonexistent. Even in major cities, connectionsare limited to the speeds available to the average home anywhere inthe U.S., 9600 bits/second. Typically, even if one of these countries is "on the Internet," only a few sites are accessible. Usually, this is the major technical university for that country. However, as phone systems improve, you can expect this to change too; more and more,you’ll see smaller sites (even individual home systems) connecting to the Internet.CommercializationMany big corporations have been on the Internet for years. For themost part, their participation has been limited to their research and engineering departments. The same corporations used some othernetwork (usually a private network) for their businesscommunications. After all, this IP stuff was only an academic toy.The IBM mainframes that handled their commercial data processing did the "real" networking using a protocol suite called System NetworkArchitecture (SNA).Businesses are now discovering that running multiple networks isexpensive. Some are beginning to look to the Internet for "one-stop" Krol & Hoffman [Page 8]network shopping. They were scared away in the past by policies which excluded or restricted commercial use. Many of these policies areunder review and will change. As these restrictions drop, commercial use of the Internet will become progressively more common.This should be especially good for small businesses. Motorola orStandard Oil can afford to run nationwide networks connecting theirsites, but Ace Custom Software couldn’t. If Ace has a San Jose office and a Washington office, all it needs is an Internet connection oneach end. For all practical purposes, they have a nationwidecorporate network, just like the big boys.PrivatizationRight behind commercialization comes privatization. For years, thenetworking community has wanted the telephone companies and otherfor-profit ventures to provide "off the shelf" IP connections. That is, just like you can place an order for a telephone jack in yourhouse for your telephone, you could do this for an Internetconnection. You order, the telephone installer leaves, and you plugyour computer into the Internet. Except for Bolt, Beranek and Newman, the company that ran the ARPAnet, there weren’t any takers. Thetelephone companies have historically said, "We’ll sell you phonelines, and you can do whatever you like with them." By default, theFederal government stayed in the networking business.Now that large corporations have become interested in the Internet,the phone companies have started to change their attitude. Now theyand other profit-oriented network purveyors complain that thegovernment ought to get out of the network business. After all, whobest can provide network services but the "phone companies"? They’ve got the ear of a lot of political people, to whom it appears to be a reasonable thing. If you talk to phone company personnel, many ofthem still don’t really understand what the Internet is about. Theyain’t got religion, but they are studying the Bible furiously.(Apologies to those telephone company employees who saw the lightyears ago and have been trying to drag their employers into church.) Although most people in the networking community think thatprivatization is a good idea, there are some obstacles in the way.Most revolve around the funding for the connections that are already in place. Many schools are connected because the government pays part of the bill. If they had to pay their own way, some schools wouldprobably decide to spend their money elsewhere. Major researchinstitutions would certainly stay on the net; but some smallercolleges might not, and the costs would probably be prohibitive formost secondary schools (let alone grade schools). What if the school could afford either an Internet connection or a science lab? It’sKrol & Hoffman [Page 9]unclear which one would get funded. The Internet has not yet become a "necessity" in many people’s minds. When it does, expectprivatization to come quickly.Well, enough questions about the history of the information highwaysystem. It’s time to walk to the edge of the road, try and hitch aride, and be on your way.AcknowledgmentsWe would like to thank O’Reilly & Associates for permission toreprint the chapter from their book by Ed Krol (1992), "The WholeInternet User’s Guide and Catalog."For More InformationHoffman, E. and L. Jackson. (1993) "FYI on Introducing the Internet--A Short Bibliography of Introductory Internetworking Readings forthe Network Novice," 4 p. (FYI 19, RFC 1463).To find out how to obtain this document and other on-lineintroductory readings, send an e-mail message to:nis-info@, with the following text:send access.guide.Krol, Ed. (1992) The Whole Internet User’s Guide and Catalog,O’Reilly & Associates, Sebastopol, CA. ISBN 1-56592-025-2.Quarterman, J. (1993) "Recent Internet Books," 15 p. (RFC 1432).The Internet SocietyPhone: (703) 620-8990Fax: (703) 620-0913E-mail: isoc@Krol & Hoffman [Page 10]RFC 1462 What is the Internet? May 1993 Security ConsiderationsSecurity issues are not discussed in this memo.Authors’ AddressesEd KrolComputing and Communications Service OfficeUniv. of Illinois Urbana Champaign (UIUC)1304 W SpringfieldUrbana, IL 61801Phone: (217)333-7886EMail: e-krol@Ellen HoffmanMerit Network, Inc.2901 Hubbard, Pod-GAnn Arbor, MI 48105Phone: (313) 936-3000EMail: ellen@Krol & Hoffman [Page 11]。
rfc4964.The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile A
Network Working Group A. Allen, Ed. Request for Comments: 4964 Research in Motion (RIM) Category: Informational J. Holm Ericsson T. Hallin Motorola September 2007 The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over CellularStatus of This MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.AbstractThis document describes a private Session Initiation Protocol (SIP)header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which islimited to the OMA PoC application. The P-Answer-State header isused for indicating the answering mode of the handset, which isparticular to the PoC application.Allen, et al. Informational [Page 1]Table of Contents1. Introduction (3)2. Overall Applicability (3)3. Terminology (3)4. Background for the Extension (4)5. Overview (5)6. The P-Answer-State Header (6)6.1. Requirements (8)6.2. Alternatives Considered (8)6.3. Applicability Statement for the P-Answer-State Header (9)6.4. Usage of the P-Answer-State Header (10)6.4.1. Procedures at the UA (Terminal) (11)6.4.2. Procedures at the UA (PTT Server) (11)6.4.3. Procedures at the Proxy Server (14)7. Formal Syntax (14)7.1. P-Answer-State Header Syntax (14)7.2. Table of the New Header (14)8. Example Usage Session Flows (15)8.1. Pre-Arranged Group Call Using On-Demand Session (15)8.2. 1-1 Call Using Pre-Established Session (21)9. Security Considerations (28)10. IANA Considerations (28)10.1. Registration of Header Fields (28)11. Acknowledgements (29)12. References (29)12.1. Normative References (29)12.2. Informative References (30)Allen, et al. Informational [Page 2]1. IntroductionThe Open Mobile Alliance (OMA) () is specifying the Push to talk Over Cellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions acrossdifferent participants. This document describes a private extension to address specific requirements of the PoC service and may not beapplicable to the general Internet.The PoC service allows a SIP User Agent (UA) (PoC terminal) toestablish a session to one or more SIP UAs simultaneously, usuallyinitiated by the initiating user pushing a button.OMA has defined a collection of very stringent requirements insupport of the PoC service. In order to provide the user with asatisfactory experience, the initial session establishment (from the time the user presses the button to the time they get an indicationto speak) must be minimized.2. Overall ApplicabilityThe SIP extension specified in this document makes certainassumptions regarding network topology and the existence oftransitive trust. These assumptions are generally NOT APPLICABLE in the Internet as a whole. The mechanism specified here was designedto satisfy the requirements specified by the Open Mobile Alliance for Push to talk over Cellular for which either no general-purposesolution was found, where insufficient operational experience wasavailable to understand if a general solution is needed, or where amore general solution is not yet mature. For more details about the assumptions made about this extension, consult the applicabilitystatement in section 6.3.3. TerminologyThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1].The terms "PTT Server" (Push to talk Server), "UnconfirmedIndication", "Unconfirmed Response", "Confirmed Indication", and"Confirmed Response" are introduced in this document.A "PTT Server" as referred to here is a SIP network server thatperforms the network-based functions for the Push to talk service.The PTT Server can act as a SIP Proxy (as defined in [2]) or a back-Allen, et al. Informational [Page 3]to-back UA (B2BUA) (as defined in [2]) based on the functions itneeds to perform. There can be one or more PTT Servers involved in a SIP Push to talk session.An "Unconfirmed Indication" as referred to here is an indication that the final target UA for the request has yet to be contacted and anintermediate SIP node is indicating that it has information thathints that the request is likely to be answered by the target UA.An "Unconfirmed Response" is a SIP 18x or 2xx response containing an "Unconfirmed Indication".A "Confirmed Indication" as referred to here is an indication thatthe target UA has accepted the session invitation and is ready toreceive media.A "Confirmed Response" is a SIP 200 (OK) response containing a"Confirmed Indication" and has the usual semantics of a SIP 200 (OK) response containing an answer (such as a Session Description Protocol (SDP) answer).4. Background for the ExtensionThe PoC terminal could support such hardware capabilities as aspeakerphone and/or headset and software that provide the capability for the user to configure the PoC terminal to accept the sessioninvitations immediately and play out the media as soon as it isreceived without requiring the intervention of the called user. This mode of operation is known as Automatic Answer mode. The user canalternatively configure the PoC terminal to first alert the user and require the user to manually accept the session invitation beforemedia is accepted. This mode of operation is known as Manual Answer mode. The PoC terminal could support both or only one of these modes of operation. The user can change the Answer Mode (AM) configuration of the PoC terminal frequently based on their current circumstancesand preference (perhaps because the user is busy, or in a public area where she cannot use a speakerphone, etc.).The OMA PoC Architecture [3] utilizes PTT Servers within the network that can perform such roles as a conference focus [10], a real-timetransport protocol (RTP) translator, or a network policy enforcement server. A possible optimization to minimize the delay in theproviding of the caller with an indication to speak is for the PTTserver to perform buffering of media packets in order to provide anearly or "Unconfirmed Indication" back to the caller and allow thecaller to start speaking before the called PoC terminal has answered. An event package and mechanisms for a SIP UA to indicate its current answer mode to a PTT Server in order to enable buffering are defined Allen, et al. Informational [Page 4]in [11]. In addition, particularly when multiple domains areinvolved in the session, more than one PTT Server could be involvedin the signaling path for the session. Also, the PTT Server thatperforms the buffering might not be the PTT Server that has knowledge of the current answer mode of the SIP UA that is the finaldestination for the SIP INVITE request. A mechanism is defined in[12] that allows a terminal that acts as a SIP UA (or as a PTT Server that acts as a SIP UA) to indicate a preference to the finaldestination SIP User Agent Server (UAS) to answer in a particularmode. However, a mechanism is required for a PTT Server to relay the "Unconfirmed Indication" in a response back towards the originatingSIP User Agent Client (UAC).5. OverviewThe purpose of this extension is to support an optimization thatmakes it possible for the network to provide a faster push to talkexperience, through an intermediate SIP user agent (PTT Server)providing a SIP 200 (OK) response before the called UA does, and aPTT Server buffering the media generated by the calling UA for replay to the called UA when it answers. Because of the half-duplex nature of the call, where media bursts are short typically in the order of10-30 seconds, the additional end-to-end latency can be tolerated,and this considerably improves the user experience. However, the PTT Server only can do this when there is a high probability that thecalled SIP UA is in Automatic Answer mode. It is likely that PTTServers near the called UA have up-to-date knowledge of the answering mode of the called UA, and due to the restricted bandwidth nature of the cellular network, they can pass upstream an indication of thecalled SIP UA’s answering mode faster than the called UA can deliver an automatically generated SIP 200 (OK) response.This document proposes a new SIP header field, the P-Answer-Stateheader field to support an "Unconfirmed Indication". The new SIPheader field can be optionally included in a response to a SIP INVITE request, or in a sipfrag of a response included in a SIP NOTIFYrequest sent as a result of a SIP REFER request that requests a SIPINVITE request to be sent. The header field is used to provide anindication from a PTT Server acting as a SIP proxy or back-to-back UA that it has information that hints that the terminating UA willlikely answer automatically. This provides an "UnconfirmedIndication" back towards the inviting SIP UA to transmit media prior to receiving a final response from the final destination of the SIPINVITE request. No Supported or Require headers are needed becausethe sender of the P-Answer-State header field does not depend on the receiver to understand the extension. If the extension is notunderstood, the header field is simply ignored by the recipient. The extension is described below.Allen, et al. Informational [Page 5]Thus, when a PTT Server forwards a SIP INVITE request and knows that the called UA is likely to be in Automatic Answer mode, it alsogenerates a SIP 183 provisional response with a P-Answer-State header field with a parameter of "Unconfirmed" to signal to upstream PTTServers that they can buffer the caller’s media.A PTT Server that wishes to buffer the caller’s media, upon seeingthe provisional response with a P-Answer-State header field with aparameter of "Unconfirmed", absorbs it and generates a SIP 200 (OK)response for the caller’s SIP UA with an appropriate answer.When the called UA generates a SIP 200 (OK) response, the PTT Server that generated the provisional response with a P-Answer-State header field with a parameter "Unconfirmed" adds to the SIP 200 (OK)response a P-Answer-State header field with a parameter of"Confirmed". The SIP 200 (OK) response is absorbed by the PTT Server that is buffering the caller’s media, as it has already generated aSIP 200 (OK) response. The buffering PTT Server then starts playing out the buffered media.6. The P-Answer-State HeaderThe purpose of the P-Answer-State header field is to provide anindication from a PTT Server acting as a SIP proxy or back-to-back UA that it has information that hints that the terminating UA identified in the Request-URI of the request will likely answer automatically.Thus, it enables the PTT Server to provide an "UnconfirmedIndication" back towards the inviting SIP UA permitting it totransmit media prior to receiving a final response from the finaldestination of the SIP INVITE request. If a provisional responsecontains the P-Answer-State header field with the value "Unconfirmed" and does not contain an answer, then a receiving PTT Server can send a SIP 200 (OK) response containing an answer and a P-Answer-Stateheader field with the value "Unconfirmed" if the PTT Server iswilling to perform media buffering. If the response containing theP-Answer-State header field with the value "Unconfirmed" alsocontains an answer, the PTT Server that included the P-Answer-Stateheader field and answer in the response is also indicating that it is willing to buffer the media until a final "Confirmed Indication" isreceived.The P-Answer-State header field can be included in a provisional orfinal response to a SIP INVITE request or in the sipfrag of a SIPNOTIFY request sent as a result of a SIP REFER request to send a SIP INVITE request. If the P-Answer-State header field with value"Unconfirmed" is included in a provisional response that contains an answer, the PTT Server is leaving the decision of where to dobuffering to other PTT Servers upstream and will forward upstream a Allen, et al. Informational [Page 6]"Confirmed indication" in a SIP 200 (OK) response when the finalresponse is received from the destination UA.NOTE It is not intended that multiple PTT Servers perform bufferingserially. If a PTT Server includes an answer along with P-Answer-State header field with the value "Unconfirmed" in a provisionalresponse, then a receiving PTT Server can determine whether itbuffers the media or forwards the media and allows the downstrean PTT Server that sent the "Unconfirmed Indication" to buffer the media.It is intended that if a PTT Server buffers media, it does so until a final "Confirmed Indication" is received, and therefore serialbuffering by multiple PTT Servers does not take place.The P-Answer-State header is only included in a provisional response when the node that sends the response has knowledge that there is aPTT Server acting as a B2BUA that understands this extension in thesignaling path between itself and the originating UAC. This PTTServer between the sending node and the originating UAC will onlypass the header field on in either a SIP 200 (OK) response or in the sipfrag (as defined in [4]) of a SIP NOTIFY request (as defined in[5]) sent as a result of a SIP REFER request (as defined in [6]).Such a situation only occurs with specific network topologies, which is another reason why use of this header field is not relevant to the general Internet. The originating UAC will only receive theP-Answer-state header field in a SIP 200 (OK) response or in thesipfrag of a SIP NOTIFY request.Provisional responses containing the P-Answer-State header field can be sent reliably using the mechanism defined in [13], but this is not required. This is a performance optimization, and the impact of aprovisional response sent unreliably (failing to arrive) is simplythat buffering does not take place. However, if the provisionalresponses are sent reliably and the provisional response fails toarrive, the time taken for the provisional response sender to timeout on the receipt of a SIP PRACK request is likely to be such that, by the time the provisional response has been resent, the "Confirmed Response" could have already been received. When provisionalresponses that contain an answer are sent reliably, the 200 (OK)response for the SIP INVITE request cannot be sent before the SIPPRACK request is received. Therefore, sending provisional responses reliably could potentially delay the sending of the "ConfirmedResponse".Allen, et al. Informational [Page 7]6.1. RequirementsThe OMA PoC service has initial setup performance requirements thatcan be met by a PTT Server acting as a B2BUA spooling media from the inviting PoC subscriber until one or more invited PoC subscribershave accepted the session. The specific requirements are:REQ-1: An intermediate server MAY spool media from the inviting SIP UA until one or more invited PoC SIP UASs has accepted theinvitation.REQ-2: An intermediate server that is capable of spooling media MAY accept a SIP INVITE request from an inviting SIP UAC even if noinvited SIP UAS has accepted the SIP INVITE request if it has ahint that the invited SIP UAS is likely to accept the requestwithout requiring user intervention.REQ-3: An intermediate server or proxy that is incapable of spooling media or does not wish to, but has a hint that the invited SIP UAS is likely to automatically accept the session invitation, MUST be able to indicate back to another intermediate server that canspool media that it has some hint that the invited UAS is likelyto automatically accept the session invitation.REQ-4: An intermediate server that is willing to spool media fromthe inviting SIP UAC until one or more invited SIP UASs haveaccepted the SIP INVITE request SHOULD indicate that it isspooling media to the inviting SIP UAC.6.2. Alternatives ConsideredIn order to meet REQ-3, a PTT Server needs to receive an indicationback that the invited SIP UA is likely to accept the SIP INVITErequest without requiring user intervention. In this case, the PTTServer that has a hint that the invited SIP UAC is likely to acceptthe request can include an answer state indication in the SIP 183(Session Progress) response or SIP 200 (OK) response.A number of alternatives were considered for the PTT Server to inform another PTT Server or the inviting SIP UAC of the invited PoC SIPUAS’s answer mode settings.One proposal was to create a unique reason-phrase in the SIP 183response and SIP 200 (OK) response. This was rejected because thereason phrases are normally intended for human readers and not meant to be parsed by servers for special syntactic and semantic meaning. Allen, et al. Informational [Page 8]Another proposal was to use a Reason header [14] in the SIP 183response and SIP 200 (OK) response. This was rejected because thiswould be inconsistent with the intended use of the Reason header and its usage is not defined for these response codes and would haverequired creating and registering a new protocol identifier.Another proposal was to use a feature-tag in the returned Contactheader as defined in [15]. This was rejected because it was not adifferent feature, but is an attribute of the session and can beapplied to many different features.Another proposal was to use a new SDP attribute. The choice of anSDP parameter was rejected because the answer state applies to thesession and not to a media stream.The P-Answer-State header was chosen to give additional informationabout the state of the SIP session progress and acceptance. Eventhough the UAC sees that its offer has been answered and accepted,the header lets the UAC know whether the invited PoC subscriber orjust an intermediary has accepted the SIP INVITE request.6.3. Applicability Statement for the P-Answer-State HeaderThe P-Answer-State header is applicable in the followingcircumstances:o In networks where there are UAs that engage in half-duplexcommunication where there is not the possibility for the inviteduser to verbally acknowledge the answering of the session as isnormal in full-duplex communication;o Where the invited UA can automatically accept the session withoutuser intervention;o The network also contains intermediate network SIP servers that are trusted;o The intermediate network SIP servers have knowledge of the current answer mode setting of the terminating UAS; and,o The intermediate network SIP servers have knowledge of the mediatypes and codecs likely to be accepted by the terminating UAS; and, o The intermediate network SIP servers can provide buffering of themedia in order to reduce the time for the inviting user to sendmedia.Allen, et al. Informational [Page 9]o The intermediate network SIP servers assume knowledge of thenetwork topology and the existence of similar intermediate network SIP servers in the signaling path.Such configurations are generally not applicable to the Internet as a whole where such trust relationships do not exist.In addition, security issues have only been considered for networksthat are trusted and use hop-by-hop security mechanisms withtransitive trust. Security issues with usage of this mechanism inthe general Internet have not been evaluated.6.4. Usage of the P-Answer-State HeaderA UAS, B2BUA, or proxy MAY include a P-Answer-State header field inany SIP 18x or 2xx response that does not contain an offer, sent inresponse to an offer contained in a SIP INVITE request as specifiedin [7]. Typically, the P-Answer-State header field is included ineither a SIP 183 Session Progress or a SIP 200 (OK) response. A UAthat receives a SIP REFER request to send a SIP INVITE request MAYalso include a P-Answer-State header field in the sipfrag of aresponse included in a SIP NOTIFY request it sends as a result of the implicit subscription created by the SIP REFER request.When the P-Answer-State header field contains the parameter"Unconfirmed", the UAS or proxy is indicating that it has information that hints that the final destination UAS for the SIP INVITE request is likely to automatically accept the session, but that this isunconfirmed and it is possible that the final destination UAS willfirst alert the user and require manual acceptance of the session or not accept the session request. When the P-Answer-State header field contains the parameter "Confirmed", the UAS or proxy is indicatingthat the destination UAS has accepted the session and is ready toreceive media. The parameter value of "Confirmed" has the usualsemantics of a SIP 200 (OK) response containing an answer and isincluded for completeness. A parameter value of "Confirmed" is only included in a SIP 200 (OK) response or in the sipfrag of a 200 (OK)contained in the body of a SIP NOTIFY request.A received SIP 18x response without a P-Answer-State header fieldSHOULD NOT be treated as an "Unconfirmed Response". A SIP 18xresponse containing a P-Answer-State header field containing theparameter "Confirmed" MUST NOT be treated as a "Confirmed Response"because this is an invalid condition.A SIP 200 (OK) response without a P-Answer-State Header field MUST be treated as a "Confirmed Response".Allen, et al. Informational [Page 10]6.4.1. Procedures at the UA (Terminal)A UAC (terminal) that receives an "Unconfirmed Response" containingan answer MAY send media as specified in [7]; however, there is noguarantee that the media will be received by the final recipient.How a UAC confirms whether or not the media was received by the final destination when it has received a SIP 2xx response containing an"Unconfirmed Indication" is application specific and outside of thescope of this document. If the application is a conference then the mechanism specified in [7] could be used to determine that theinvited user joined. Alternatively, a SIP BYE request could bereceived or the media could be placed on hold if the finaldestination UAS does not accept the session.A UAC (terminal) that receives, in response to a SIP REFER request, a SIP NOTIFY request containing an "Unconfirmed Response" in a sipfrag in the body of the SIP NOTIFY request related to a dialog for whichthere has been a successful offer-answer exchange according to [5]MAY send media. However, there is no guarantee that the media willbe received by the final recipient that was indicated in the Refer-To header in the original SIP REFER request. The dialog could berelated either because the SIP REFER request was sent on the samedialog or because the SIP REFER request contained a Target-Dialogheader, as defined in [16], that identified the dialog.A UAC (terminal) that receives an "Unconfirmed Response" that doesnot contain an answer MAY buffer media until it receives another"Unconfirmed Response" containing an answer or a "ConfirmedResponse".There are no P-Answer-State procedures for a terminal acting in theUAS role.6.4.2. Procedures at the UA (PTT Server)A PTT Server that receives a SIP INVITE request at the UAS part ofits back-to-back UA MAY include, in any SIP 18x or 2xx response that does not contain an offer, a P-Answer-State header field with theparameter "Unconfirmed" in the response if it has not yet received a "Confirmed Response" from the final destination UA, and it hasinformation that hints that the final destination UA for the SIPINVITE request is likely to automatically accept the session.A PTT Server that receives a SIP 18x response to a SIP INVITE request containing a P-Answer-State header field with the parameter"Unconfirmed" at the UAC part of its back-to-back UA MAY include the P-Answer-State header field with the parameter "Unconfirmed" in a SIP Allen, et al. Informational [Page 11]2xx response that the UAS part of its back-to-back UA sends as aresult of receiving that response. Otherwise, a PTT Server thatreceives a SIP 18x or 2xx response to a SIP INVITE request containing a P-Answer-State header field at the UAC part of its back-to-back UA SHOULD include the P-Answer-State header field unmodified in the SIP 18x or 2xx response that the UAS part of its back-to-back UA sends as a result of receiving that response. If the response sent by the UAS part of its back-to-back UA is a SIP 18x response, then theP-Answer-State header field included in the response MUST contain aparameter of "Unconfirmed".The UAS part of the back-to-back UA of a PTT Server MAY include ananswer in the "Unconfirmed Response" it sends even if the"Unconfirmed Response" received by the UAC part of the back-to-backUA did not contain an answer.If a PTT Server receives a "Confirmed Response" at the UAC part ofits back-to-back UA, then the UAS part of its back-to-back UA MAYinclude in the forwarded response a P-Answer-State header field with the parameter "Confirmed". If the UAS part of its back-to-back UApreviously sent an "Unconfirmed Response" as part of this dialog, the UAS part of its back-to-back UA SHOULD include in the forwarded"Confirmed Response" a P-Answer-State header field with the parameter "Confirmed".If the UAS part of the back-to-back UA of a PTT Server includes ananswer in a response along with a P-Answer-State header field withthe parameter "Unconfirmed", then the UAS part of its back-to-back UA needs to be ready to receive media as specified in [7]. Also, it MAY buffer any media it receives until it receives a "Confirmed Response" from the final destination UA or until its buffer is full.A UAS part of the back-to-back UA of a PTT Server that receives a SIP REFER request to send a SIP INVITE request to another UA, asspecified in [6], MAY generate a sipfrag of a SIP 200 (OK) responsecontaining a P-Answer-State header field with the parameter"Unconfirmed" prior to the UAC part of its back-to-back UA receiving a response to the SIP INVITE request, if it has information thathints that the final destination UA for the SIP INVITE request islikely to automatically accept the session.If the UAC part of a back-to-back UA of a PTT Server sent a SIPINVITE request as a result of receiving a SIP REFER Request, receives a SIP 18x or 2xx response containing a P-Answer-State header field at the UAC part of its back-to-back UA, then the UAS part of its back-to-back UA SHOULD include the P-Answer-State header field in thesipfrag of the response contained in a SIP NOTIFY request. TheP-Answer-State header field that is contained in the sipfrag,Allen, et al. Informational [Page 12]。
rfc2782.A DNS RR for specifying the location of services (DNS SRV)
Network Working Group A. Gulbrandsen Request for Comments: 2782 Troll Technologies Obsoletes: 2052 P. Vixie Category: Standards Track Internet Software Consortium L. Esibov Microsoft Corp. February 2000 A DNS RR for specifying the location of services (DNS SRV)Status of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2000). All Rights Reserved.AbstractThis document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain.Overview and rationaleCurrently, one must either know the exact address of a server tocontact it, or broadcast a question.The SRV RR allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and todesignate some hosts as primary servers for a service and others asbackups.Clients ask for a specific service/protocol for a specific domain(the word domain is used here in the strict RFC 1034 sense), and get back the names of any available servers.Note that where this document refers to "address records", it means A RR’s, AAAA RR’s, or their most modern equivalent.Gulbrandsen, et al. Standards Track [Page 1]DefinitionsThe key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"used in this document are to be interpreted as specified in [BCP 14]. Other terms used in this document are defined in the DNSspecification, RFC 1034.Applicability StatementIn general, it is expected that SRV records will be used by clientsfor applications where the relevant protocol specification indicates that clients should use the SRV record. Such specification MUSTdefine the symbolic name to be used in the Service field of the SRVrecord as described below. It also MUST include securityconsiderations. Service SRV records SHOULD NOT be used in the absence of such specification.Introductory exampleIf a SRV-cognizant LDAP client wants to discover a LDAP server thatsupports TCP protocol and provides LDAP service for the domain., it does a lookup of_ldap._as described in [ARM]. The example zone file near the end of thismemo contains answering RRs for an SRV query.Note: LDAP is chosen as an example for illustrative purposes only,and the LDAP examples used in this document should not be considered a definitive statement on the recommended way for LDAP to use SRVrecords. As described in the earlier applicability section, consultthe appropriate LDAP documents for the recommended procedures.The format of the SRV RRHere is the format of the SRV RR, whose DNS type code is 33:_Service._ TTL Class SRV Priority Weight Port Target(There is an example near the end of this document.)ServiceThe symbolic name of the desired service, as defined in Assigned Numbers [STD 2] or locally. An underscore (_) is prepended tothe service identifier to avoid collisions with DNS labels that occur in nature.Gulbrandsen, et al. Standards Track [Page 2]Some widely used services, notably POP, don’t have a singleuniversal name. If Assigned Numbers names the serviceindicated, that name is the only name which is legal for SRVlookups. The Service is case insensitive.ProtoThe symbolic name of the desired protocol, with an underscore(_) prepended to prevent collisions with DNS labels that occurin nature. _TCP and _UDP are at present the most useful values for this field, though any name defined by Assigned Numbers orlocally may be used (as for Service). The Proto is caseinsensitive.NameThe domain this RR refers to. The SRV RR is unique in that the name one searches for is not this name; the example near the end shows this clearly.TTLStandard DNS meaning [RFC 1035].ClassStandard DNS meaning [RFC 1035]. SRV records occur in the INClass.PriorityThe priority of this target host. A client MUST attempt tocontact the target host with the lowest-numbered priority it can reach; target hosts with the same priority SHOULD be tried in an order defined by the weight field. The range is 0-65535. This is a 16 bit unsigned integer in network byte order.WeightA server selection mechanism. The weight field specifies arelative weight for entries with the same priority. Largerweights SHOULD be given a proportionately higher probability of being selected. The range of this number is 0-65535. This is a 16 bit unsigned integer in network byte order. Domainadministrators SHOULD use Weight 0 when there isn’t any serverselection to do, to make the RR easier to read for humans (less noisy). In the presence of records containing weights greaterthan 0, records with weight 0 should have a very small chance of being selected.In the absence of a protocol whose specification calls for theuse of other weighting information, a client arranges the SRVRRs of the same Priority in the order in which target hosts, Gulbrandsen, et al. Standards Track [Page 3]specified by the SRV RRs, will be contacted. The followingalgorithm SHOULD be used to order the SRV RRs of the samepriority:To select a target to be contacted next, arrange all SRV RRs(that have not been ordered yet) in any order, except that allthose with weight 0 are placed at the beginning of the list.Compute the sum of the weights of those RRs, and with each RRassociate the running sum in the selected order. Then choose auniform random number between 0 and the sum computed(inclusive), and select the RR whose running sum value is thefirst in the selected order which is greater than or equal tothe random number selected. The target host specified in theselected SRV RR is the next one to be contacted by the client.Remove this SRV RR from the set of the unordered SRV RRs andapply the described algorithm to the unordered SRV RRs to select the next target host. Continue the ordering process until there are no unordered SRV RRs. This process is repeated for eachPriority.PortThe port on this target host of this service. The range is 0-65535. This is a 16 bit unsigned integer in network byte order. This is often as specified in Assigned Numbers but need not be. TargetThe domain name of the target host. There MUST be one or moreaddress records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181). Implementors are urged, but not required, to return the address record(s) in the Additional Data section. Unless and until permitted by future standardsaction, name compression is not to be used for this field.A Target of "." means that the service is decidedly notavailable at this domain.Domain administrator adviceExpecting everyone to update their client applications when the first server publishes a SRV RR is futile (even if desirable). ThereforeSRV would have to coexist with address record lookups for existingprotocols, and DNS administrators should try to provide addressrecords to support old clients:- Where the services for a single domain are spread over severalhosts, it seems advisable to have a list of address records atthe same DNS node as the SRV RR, listing reasonable (if perhaps Gulbrandsen, et al. Standards Track [Page 4]suboptimal) fallback hosts for Telnet, NNTP and other protocols likely to be used with this name. Note that some programs only try the first address they get back from e.g. gethostbyname(),and we don’t know how widespread this behavior is.- Where one service is provided by several hosts, one can eitherprovide address records for all the hosts (in which case theround-robin mechanism, where available, will share the loadequally) or just for one (presumably the fastest).- If a host is intended to provide a service only when the mainserver(s) is/are down, it probably shouldn’t be listed inaddress records.- Hosts that are referenced by backup address records must use the port number specified in Assigned Numbers for the service.- Designers of future protocols for which "secondary servers" isnot useful (or meaningful) may choose to not use SRV’s supportfor secondary servers. Clients for such protocols may use orignore SRV RRs with Priority higher than the RR with the lowest Priority for a domain.Currently there’s a practical limit of 512 bytes for DNS replies.Until all resolvers can handle larger responses, domainadministrators are strongly advised to keep their SRV replies below512 bytes.All round numbers, wrote Dr. Johnson, are false, and these numbersare very round: A reply packet has a 30-byte overhead plus the nameof the service ("_ldap._" for instance); each SRV RRadds 20 bytes plus the name of the target host; each NS RR in the NS section is 15 bytes plus the name of the name server host; andfinally each A RR in the additional data section is 20 bytes or so,and there are A’s for each SRV and NS RR mentioned in the answer.This size estimate is extremely crude, but shouldn’t underestimatethe actual answer size by much. If an answer may be close to thelimit, using a DNS query tool (e.g. "dig") to look at the actualanswer is a good idea.The "Weight" fieldWeight, the server selection field, is not quite satisfactory, butthe actual load on typical servers changes much too quickly to bekept around in DNS caches. It seems to the authors that offeringadministrators a way to say "this machine is three times as fast asthat one" is the best that can practically be done.Gulbrandsen, et al. Standards Track [Page 5]The only way the authors can see of getting a "better" load figure is asking a separate server when the client selects a server andcontacts it. For short-lived services an extra step in theconnection establishment seems too expensive, and for long-livedservices, the load figure may well be thrown off a minute after theconnection is established when someone else starts or finishes aheavy job.Note: There are currently various experiments at providing relativenetwork proximity estimation, available bandwidth estimation, andsimilar services. Use of the SRV record with such facilities, and in particular the interpretation of the Weight field when thesefacilities are used, is for further study. Weight is only intendedfor static, not dynamic, server selection. Using SRV weight fordynamic server selection would require assigning unreasonably shortTTLs to the SRV RRs, which would limit the usefulness of the DNScaching mechanism, thus increasing overall network load anddecreasing overall reliability. Server selection via SRV is onlyintended to express static information such as "this server has afaster CPU than that one" or "this server has a much better networkconnection than that one".The Port numberCurrently, the translation from service name to port number happensat the client, often using a file such as /etc/services.Moving this information to the DNS makes it less necessary to update these files on every single computer of the net every time a newservice is added, and makes it possible to move standard services out of the "root-only" port range on unix.Usage rulesA SRV-cognizant client SHOULD use this procedure to locate a list of servers and connect to the preferred one:Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,QTYPE=SRV.If the reply is NOERROR, ANCOUNT>0 and there is at least oneSRV RR which specifies the requested Service and Protocol inthe reply:If there is precisely one SRV RR, and its Target is "."(the root domain), abort.Gulbrandsen, et al. Standards Track [Page 6]Else, for all such RR’s, build a list of (Priority, Weight, Target) tuplesSort the list by priority (lowest number first)Create a new empty listFor each distinct priority levelWhile there are still elements left at this prioritylevelSelect an element as specified above, in thedescription of Weight in "The format of the SRVRR" Section, and move it to the tail of the newlistFor each element in the new listquery the DNS for address records for the Target oruse any such records found in the Additional Datasection of the earlier SRV response.for each address record found, try to connect to the(protocol, address, service).elseDo a lookup for QNAME=target, QCLASS=IN, QTYPE=Afor each address record found, try to connect to the(protocol, address, service)Notes:- Port numbers SHOULD NOT be used in place of the symbolic serviceor protocol names (for the same reason why variant names cannotbe allowed: Applications would have to do two or more lookups).- If a truncated response comes back from an SRV query, the rulesdescribed in [RFC 2181] shall apply.- A client MUST parse all of the RR’s in the reply.- If the Additional Data section doesn’t contain address recordsfor all the SRV RR’s and the client may want to connect to thetarget host(s) involved, the client MUST look up the addressrecord(s). (This happens quite often when the address recordhas shorter TTL than the SRV or NS RR’s.)Gulbrandsen, et al. Standards Track [Page 7]- Future protocols could be designed to use SRV RR lookups as themeans by which clients locate their servers.Fictional exampleThis example uses fictional service "foobar" as an aid inunderstanding SRV records. If ever service "foobar" is implemented,it is not intended that it will necessarily use SRV records. This is (part of) the zone file for , a still-unused domain:$ORIGIN .@ SOA . . (1995032001 3600 3600 604800 86400 )NS .NS .NS .; foobar - use old-slow-box or new-fast-box if either is; available, make three quarters of the logins go to; new-fast-box._foobar._tcp SRV 0 1 9 .SRV 0 3 9 .; if neither old-slow-box or new-fast-box is up, switch to; using the sysdmin’s box and the serverSRV 1 0 9 .SRV 1 0 9 .server A 172.30.79.10old-slow-box A 172.30.79.11sysadmins-box A 172.30.79.12new-fast-box A 172.30.79.13; NO other services are supported*._tcp SRV 0 0 0 .*._udp SRV 0 0 0 .Gulbrandsen, et al. Standards Track [Page 8]In this example, a client of the "foobar" service in the"." domain needs an SRV lookup of"_foobar._." and possibly A lookups of "new-fast-." and/or the other hosts named. The size of the SRV reply is approximately 365 bytes:30 bytes general overhead20 bytes for the query string, "_foobar._."130 bytes for 4 SRV RR’s, 20 bytes each plus the lengths of "new- fast-box", "old-slow-box", "server" and "sysadmins-box" -"" in the query section is quoted here and doesn’tneed to be counted again.75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server", "." and "ns2" - again, "." is quoted and only needs to be counted once.120 bytes for the 6 address records (assuming IPv4 only) mentioned by the SRV and NS RR’s.IANA ConsiderationsThe IANA has assigned RR type value 33 to the SRV RR. No other IANA services are required by this document.Changes from RFC 2052This document obsoletes RFC 2052. The major change from thatprevious, experimental, version of this specification is that now the protocol and service labels are prepended with an underscore, tolower the probability of an accidental clash with a similar name used for unrelated purposes. Aside from that, changes are only intendedto increase the clarity and completeness of the document. Thisdocument especially clarifies the use of the Weight field of the SRV records.Security ConsiderationsThe authors believe this RR to not cause any new security problems.Some problems become more visible, though.- The ability to specify ports on a fine-grained basis obviouslychanges how a router can filter packets. It becomes impossibleto block internal clients from accessing specific externalservices, slightly harder to block internal users from runningunauthorized services, and more important for the routeroperations and DNS operations personnel to cooperate.- There is no way a site can keep its hosts from being referencedas servers. This could lead to denial of service.Gulbrandsen, et al. Standards Track [Page 9]- With SRV, DNS spoofers can supply false port numbers, as well ashost names and addresses. Because this vulnerability existsalready, with names and addresses, this is not a newvulnerability, merely a slightly extended one, with littlepractical effect.ReferencesSTD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.RFC 1034: Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.RFC 1035: Mockapetris, P., "Domain names - Implementation andSpecification", STD 13, RFC 1035, November 1987.RFC 974: Partridge, C., "Mail routing and the domain system", STD14, RFC 974, January 1986.BCP 14: Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNSSpecification", RFC 2181, July 1997.RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network Services", BCP 17, RFC 2219, October 1997.BCP 14: Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.ARM: Armijo, M., Esibov, L. and P. Leach, "Discovering LDAPServices with DNS", Work in Progress.KDC-DNS: Hornstein, K. and J. Altman, "Distributing Kerberos KDC and Realm Information with DNS", Work in Progress.Gulbrandsen, et al. Standards Track [Page 10]AcknowledgementsThe algorithm used to select from the weighted SRV RRs of equalpriority is adapted from one supplied by Dan Bernstein.Authors’ AddressesArnt GulbrandsenTroll TechWaldemar Thranes gate 98BN-0175 Oslo, NorwayFax: +47 22806380Phone: +47 22806390EMail: arnt@troll.noPaul VixieInternet Software Consortium950 Charter StreetRedwood City, CA 94063Phone: +1 650 779 7001Levon EsibovMicrosoft CorporationOne Microsoft WayRedmond, WA 98052EMail: levone@Gulbrandsen, et al. Standards Track [Page 11]Full Copyright StatementCopyright (C) The Internet Society (2000). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Gulbrandsen, et al. Standards Track [Page 12]。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Network Working Group G. Malkin Request for Comments: 1207 FTP Software, Inc. FYI: 7 A. Marine SRI J. Reynolds ISI February 1991 FYI on Questions and AnswersAnswers to Commonly asked "Experienced Internet User" Questions Status of this MemoThis FYI RFC is one of two FYI’s called, "Questions and Answers"(Q/A), produced by the User Services Working Group of the InternetEngineering Task Force (IETF). The goal is to document the mostcommonly asked questions and answers in the Internet.This memo provides information for the Internet community. It doesnot specify any standard. Distribution of this memo is unlimited. Table of Contents1. Introduction (1)2. Acknowledgements (3)3. Questions about the Internet (3)4. Questions About Other Networks and Internets (3)5. Questions About Internet Documentation (4)6. Questions About the Domain Name System (DNS) (4)7. Questions About Network Management (7)8. Questions about Serial Line Internet Protocol (SLIP) andPoint-to-Point Protocol (PPP) Implementations (9)9. Questions About Routing (11)10. Other Protocol and Standards Implementation Questions (11)11. Suggested Reading (12)12. References (13)13. Security Considerations (14)14. Authors’ Addresses (15)1. IntroductionDuring the last few months, several people have monitored variousmajor mailing lists and have extracted questions that are importantor commonly asked. This FYI RFC is one of two in a series of FYI’swhich present the questions and their answers. The first FYI, FYI 4, presented questions new Internet users commonly ask and theiranswers.User Services Working Group [Page 1]The goal of this FYI is to codify the Internet lore so that networkoperations staff, especially for networks just joining the Internet, will have an accurate and up to date set of references from which to work. Also, redundancies are moved away from the electronic mailing lists so that the lists’ subscribers do not have to read the samequeries and answers over and over again.Although the questions and their responses are taken from variousmailing lists, they are presented here loosely grouped by relatedtopic for ease of reading. First the question is presented, then the answer (or answers) as it appeared on the mailing list.Sometimes the answers are abridged for better use of space. If aquestion was not answered on the mailing list, the editors provide an answer. These answers are not distinguished from the answers foundon the lists. Sometimes, in order to be as complete as possible, the editors provide additional information that was not present in theoriginal answer. If so, that information falls under the heading"Additional Information".The answers are as correct as the reviewers can make them. However, much of this information changes with time. As the FYI is updated,temporal errors will be corrected.Many of the questions are in first person, and the answers weredirected to the originator of the question. These phrasings have not been changed except where necessary for clarity. References to thecorrespondents’ names have been removed.The Q/A mailing lists are maintained by Gary Malkin at . They are used by a subgroup of the User Services Working Group to discuss the Q/A FYIs. They include:quail@ This is a discussion mailing list. Itsprimary use is for pre-release review ofthe Q/A FYIs.quail-request@ This is how you join the quail mailing list. quail-box@ This is where the questions and answerswill be forwarded-and-stored. It isnot necessary to be on the quail mailinglist to forward to the quail-box.User Services Working Group [Page 2]2. AcknowledgmentsThe following people deserve thanks for their help and contributions to this FYI Q/A: Jim Conklin (EDUCOM), John C. Klensin (MIT),Professor Kynikos (Special Consultant), Jon Postel (ISI),Marshall Rose (PSI, Inc.), David Sitman (Tel Aviv University),Patricia Smith (Merit), Gene Spafford (Purdue), andJames Van Bokkelen (FTP Software, Inc.).3. Questions about the Internet3.1. How do I get statistics regarding the traffic on NSFNET?Merit/NSFNET Information Services maintains a variety ofstatistical data at ’’ (35.1.1.48) in the ’stats’directory. Information includes packet counts by NSS and bytecounts for type of use (ftp, smtp, telnet, etc.). Filenames areof the form ’NSFyy-mm.type’.Files are available for anonymous ftp; use ’guest’ as thepassword.The data in these files represent only traffic which traverses the highest level of the NSFNET, not traffic within a campus orregional network. Send questions/comments to nsfnet-info@.4. Questions About Other Networks and Internets4.1. We have a user who would like to access a machine on"EARN/BITNET". I can’t find anything on this in the domainname tables. Please, what is this, and how do I connect to it? There are several machines on the Internet that act as gatewaysbetween the Internet and BITNET. Two examples are and . You can address a mail message touser%nodename.bitnet@ where the message will bepassed from the Internet to BITNET.Additional Information:These same gateways, known as INTERBIT on the BITNET/EARN side, transfer mail from computers on that network which support SMTP mail headers, onto the Internet. (Many BITNET/EARN computersstill do not support SMTP, which is not a part of the IBMprotocol used, and it is not possible to send mail from thosecomputers across the gateways into the Internet, in general.) User Services Working Group [Page 3]BITNET and EARN are the two largest of several cooperatingnetworks which use the IBM RSCS/NJE protocol suite, but are not limited to IBM systems. These independently administered,interconnected networks function as a single, worldwide network directly connecting more than 3,300 computers in about 1,400,mostly higher-education, organizations worldwide. Thisworldwide network supports electronic mail, including mailinglists, sender-initiated file transfer, and short "interactive" messages.BITNET, frequently used (outside of Europe) to refer to thewhole worldwide network, technically refers to that portion in the United States, plus sites in other countries which areconnected through the United States and do not have their ownseparately administered cooperating networks. More than 550organizations in the U.S. participate in BITNET.EARN is the European Academic Research Network. EARN linksmore than 500 institutions in Europe and several surroundingcountries.BITNET and CSNET merged organizationally on October 1, 1990, to form CREN, the Corporation for Research and EducationalNetworking. The two networks remain separate at theoperational level level, however. (EARN and the otherCooperating Networks were not involved in this merger.)5. Questions About Internet Documentation5.1. Where do I get information regarding ordering documentsrelated to GOSIP?The complete information as issued by NIST is available online on the host as PROTOCOLS:GOSIP-ORDER-INFO.TXT. The file contains pointers to contact people, ordering addresses, prices,and, in some cases, online pathnames, for various GOSIP relateddocuments. In addition, the information as of August 1990 waspublished as an appendix to RFC 1169, "Explaining the Role ofGOSIP" [1].6. Questions About Domain Name System (DNS)6.1. Is there a DNS Query server?Actually, what you are looking for is the service that host128.218.1.109 provides on port 5555 - you simply connect to thathost at that port, type in a fully qualified domain name and itresponds with an internet address and closes the connection. I User Services Working Group [Page 4]used it when I had a host that still only had /etc/hosts and itdid just what I needed - which was basically a manual nslookup.However, the vast majority of users will find it simpler to justuse a DNS query tool and ask the DNS directly. This doesn’trequire much sophistication, and does allow the user to see howshort names are expanded at the user’s site rather than at128.218.1.109 (wherever that is). For example, suppose a userwants to find out the address of a fully-qualified domain name"", and also see what host and address are usedwhen "Z" is typed as a host name.Assuming the user is on a UNIX host and has a copy of the digprogram, type:dig anddig zand the answers will appear. You are now on your way tobecoming a DNS expert. There are other UNIX alternatives,e.g., nslookup, and similar programs for non-UNIX systems.Your local DNS guru certainly has one or more of these tools,and although they are often kept from the public, they arereally quite easy to use for simple cases.6.2. We have been having a frequent BIND failure on both our VAXand Solbourne that is traced to TCP domain queries from anIBM NSMAIN nameserver running in cache mode (UDP queries donot cause this problem, though it is usually a UDPresolution that is active upon the crash -- this resolutionis an innocent victim).I have discovered that something is trashing the hash areas(sometimes even as it is being recursively used in aresolution). Also, occasionally the socket/file descriptorfor the TCP connection is changed to invalid entries causinga reply write fail (though this is not necessarily fatal,and the rest of the structure is not apparently altered).Has any one else had frequent BIND failures (especiallymajor domain sites that have heavy TCP domain loads)?In both the case of BIND and the IBM implementation, often called FAL, there are multiple versions, with older versions being truly bad. Upgrade to recent version before exploring further.BIND has always had a problem with polluting its own database. User Services Working Group [Page 5]These problems have been related to TCP connections, NS RRs withsmall TTLs, and several other causes. Experience suggests thatthe style of bug fixing has often been that of reducing theproblem by 90% rather than eliminating it.IBM’s support for the DNS (outside of UNIX systems) is interesting in its techniques, encouraging in its improvement, but stillsomewhat depressing when compared to most other DNS software. IBM also uses terminology that varies somewhat from the usual DNSusage and preserves some archaic syntax, e.g., "..".The combination of an old BIND and an old IBM server is just plain unpleasant.6.3. Is the model used by the domain name system for host namesthat the owner of a name gets to choose its case?The model used by the DNS is that you get to control at a specific point in the name space, and are hence free to select case as you choose, until points where you in turn give away control. As apractical matter, there are several implementations that don’t do the right thing. IBM implementations often map everything into a single case.6.4. According to RFC 1034 [2], section 4.2.1, one should not haveto code glue RR’s for name server’s names unless they are below the cut. When I don’t put glue RR’s in, and do a query forNS records, the "additional" field is left blank. As far as Ican tell, all other zones I query for NS records have thisfilled with the IP addresses of the NS hosts. Is this required or should I not be concerned that the additional field is empty?The protocol says that an empty additional field is not a problem when the name server’s name is not "below" the cut.In practice, putting in the glue where it is not required cancause problems if the servers named in the glue are used forseveral zones. This is broken behavior in BIND. Not putting inglue can cause other problems in BIND, usually when the servername is difficult to resolve. So, the bottom line is to put glue in only when required, and don’t use aliases or anything elsetricky when it comes to identifying name servers.User Services Working Group [Page 6]7. Questions About Network Management Implementations7.1. In reading the SNMP RFCs [3,4,5,6] I find mention ofauthentication of PDUs. Are there any standards forauthentication mechanisms?There is a working group of the IETF that is working on thisproblem. They are close to a solution, but nothing has yetreached RFC publication yet. Expect something solid andimplementable by October of 1991.7.2. Can vendors make their enterprise-specific variables availableto users through a standard distribution mechanism?Yes. But before someone submits a MIB, they should check it outthemselves.On in pilot/snmp-wg/, there are two filesmosy-sparc-4.0.3.cmosy-sun3-3.5The first will run on a Sun-Sparc, the second will run on a Sun-3.After retrieving one of these files in BINARY mode via anonymous FTP, the submittor can run their MIB through it, e.g.,% mosy mymib.myOnce your MIB passes, send it to:mib-checker@If everything is OK, the mib-checker will arrange to have itinstalled in the /share/ftp/mib directory on .Note: This processing does not offer an official endorsement. Thedocuments submitted must not be marked proprietary, confidential,or the like.7.3. I have a question regarding those pesky octet strings again.I use the variable-type field of the Response pdu to determinehow the result should be displayed to the user. For example,I convert NetworkAddresses to their dotted decimal format("132.243.50.4"). I convert Object Identifiers into strings("1.3.6.1.2....").I would LIKE to just print Octet Strings as strings. But,User Services Working Group [Page 7]this causes a problem in such cases as atPhysAddress inwhich the Octet string contains the 6 byte address insteadof a printable ASCII string. In this case, I would want todisplay the 6 bytes instead of just trying to print thestring.MY QUESTION IS: Does anyone have a suggestion as to how Ican determine whether I can just print the string or whetherI should display the octet bytes. * Remember: I want tosupport enterprise specific variables too.In general, there is no way that you can tell what is inside anOCTET STRING without knowing something about the object that theOCTET STRING comes from. In MIB-II [6], some objects are markedas DisplayString which has the syntax of OCTET STRING but isrestricted to characters from the NVT ASCII character set (see the TELNET Specification, RFC 854 [7], for further information).These objects are:sysDescrsysContactsysNamesysLocationifDescrIf you want to be able to arbitrarily decide how to display thestrings, without knowing anything about the object, then you canscan the octets, looking for any octet which is not printableASCII. If you find at least one, you can print the entire string, octet by octet, in "%02x:" notation. If all of the octets areprintable ASCII, then you can just printf the string.7.4. If archived MIBs must be 1155-compatible [3], it would be niceif those who submit them check them first. Where are theseMIB tools available for public FTP? Ideally, a simplesyntax checker (that didn’t actually generate code) would benice.In the ISODE 6.0 release there is a tool called MOSY whichrecognizes the 1155 syntax and produces a flat ASCII file. If you can run it through MOSY without problems then you are OK.7.5. Suppose I want to create a private MIB object for causingsome action to happen, say, do a reset. Should the syntaxor this object specify a value such as:User Services Working Group [Page 8]Syntax:INTEGER {perform reset (1),}even though there is only a single value? Or, is it ok tojust allow a Set on this object with any value to performthe desired action? If the later, how is this specified?For our SNMP manageable gizmos and doohickies with similar"action" type MIB variables, I’ve defined two valuesSyntax:INTEGER {reset(1)not-reset(2)}And defined behavior so that the only valid value that thevariable may be set to is "reset" (which is returned in the getresponse PDU) and at all other times a get/getnext will respondwith "not-reset".8. Questions about Serial Line Internet Protocol (SLIP) andPoint-to-Point Protocol (PPP) Implementations8.1. I seem to recall hearing that SLIP [8] will only run onsynchronous serial lines. Is this true? ... is theresomething about SLIP which precludes it’s being implementedover async lines?Other way around: SLIP is designed for async lines and is not agood fit on sync lines. PPP [9, 10] works on either, and is what you should be implementing if you’re implementing something.8.2. Since we are very interested in standards in this area,could someone tell me were I can find more information on PPP?Also, can this protocol be used in other fields than for theInternet (i.e., telecontrol, telemetering) where we see aprofusion of proprietary incompatible and hard to maintainPoint-to-Point Protocols?PPP was designed to be useful for many protocols besides just IP. Whether it would be useful for your particular application should probably be discussed with the IETF’s Point-to-Point ProtocolWorking Group discussion list. For general discussion: ietf-ppp@. To subscribe: ietf-ppp-request@User Services Working Group [Page 9]The PPP specification is available as RFC 1171 [9], and a PPPoptions specification is available as RFC 1172 [10].In UnixWorld of April 1990 (Vol. VII, No. 4, Pg. 85), HowardBaldwin writes:"Point-to-Point Protocol (PPP) has just been submitted to theCCITT from the Internet Engineering Task Force. It specifies a standard for encapsulating Internet Protocol data and othernetwork layer (level three on ISO’s OSI Model) protocolinformation over point-to-point links; it also provides ways to test and configure lines and the upper level protocols on theOSI Model. The only requirement is a provision of a duplexcircuit either dedicated or switched, that can operate ineither an asynchronous or synchronous mode, transparent to the data-linklayer frame."According to Michael Ballard, director of network systems for Telebit, PPP is a direct improvement upon Serial Line Internet Protocol (SLIP), which had neither error correction nor a wayto exchange network address."8.3. Does anyone know if there is a way to run a SLIP program ona IBM computer running SCO Xenix/Unix, with a multi-portserial board?SCO TCP/IP for Xenix supports SLIP. It works. However, bewarned: SCO SLIP works *only* with SCO serial drivers, so it will *not* work with intelligent boards that come with their owndrivers. If you want lots of SLIP ports, you’ll need lots of dumb ports, perhaps with a multi-dumb-port board.Here’s the setup -- SunOS 3.5, with the 4.3BSD TCP, IP & SLIPdistributions installed. Slip is running between the "ttya" ports of two Sun 3/60’s. "ping", "rlogin", etc., works fine, but a NFS mount results in "server not responding: RPC Timed Out".SunOS 3.5 turns the UDP checksum off, which is legal and worksokay over interfaces such as ethernet which has link- levelchecksumming. On the other hand, SLIP doesn’t perform checksumsthus running NFS over SLIP requires you to turn the UDP checksumon. Otherwise, you’ll experience erratic behavior such as the one described above.User Services Working Group [Page 10]Save the older kernel and try,% adb -k -w /vmunix /dev/kmem udpcksum?w 1to patch up the kernel.9. Questions About Routing9.1. Some postings mentioned "maximum entropy routing". Couldsomeone please provide a pointer to on-line or off-linereferences to this topic?Try NYU CSD Technical Report 371: "Some Comments on Highly Dynamic Network Routing," by Herbert J. Bernstein, May 1988.10. Other Protocol and Standards Implementation Questions10.1. Does anyone recognize ethernet type "80F3"? I don’t see itin RFC 1010, but I am seeing it on our net.Ethernet type 0x80F3 is used by AppleTalk for address resolution. You must have Macs on your network which are directly connected to Ethernet. These packets are used by the Mac (generally atstartup) to determine a valid AppleTalk node number.Additional Information:RFC 1010 is obsolete. Please consult RFC 1060 [11], the current"Assigned Numbers" (issued March 1990), which does list "80F3":Ethernet Exp. Ethernet Description References ------------- ------------- ----------- ---------- decimal Hex decimal octal33011 80F3 - - AppleTalk AARP (Kinetics)[XEROX] 10.2. Does anyone know the significance of a high value for"Bad proto" in the output from netstat on Unix machines usingethernet? We’re seeing values in the tens of thousands out of a few hundred thousand packets sent/received in all. Some"Bad proto" values are negative, too. (Off the scale?) Anyhelp would be appreciated.This probably indicates that you are getting tens of thousands of broadcast packets from some host or hosts on your network. Youmight want to buy or rent a LAN monitor, or install one of thepublic-domain packages to see what private protocol is guilty."FYI on a Network Management Tool Catalog: Tools for Monitoringand Debugging TCP/IP Internets and Interconnected Devices" (RFC User Services Working Group [Page 11]1147, FYI 2), [12] contains pointers to tools that may help youzero in on the problem.10.3. Which RFC would explain the proper way to configure broadcastaddresses when using subnets?Consult RFC 1122, "Requirements for Internet Hosts --Communication Layer" [13].10.4. Can anyone tell me what .TAR files exactly are? Is it likeZIP or LZH for the IBM PC’s? IF so, how do I go about getting a compressor/decompressor for .TAR files and what computerdoes this run on?TAR stands for "Tape ARchive". It is a Unix utility which takesfiles, and directories of files, and creates a single large file. Originally intended to back up directory trees onto tape (hencethe name), TAR is also used to combine files for easier electronic file transfer.11. Suggested ReadingFor further information about the Internet and its protocols ingeneral, you may choose to obtain copies of the following works:Bowers, K., T. LaQuey, J. Reynolds, K. Roubicek, M. Stahl, and A. Yuan, "Where to Start - A Bibliography of General Internetworking Information", RFC 1175, FYI 3, CNRI, U Texas, ISI, BBN, SRI,Mitre, August 1990.Braden, R., Editor, "Requirements for Internet Hosts --Communication Layer", RFC 1122, Internet Engineering Task Force,October 1989.Braden, R., Editor, "Requirements for Internet Hosts --Application and Support", RFC 1123, Internet Engineering TaskForce, October 1989.Comer, D., "Internetworking with TCP/IP: Principles, Protocols,and Architecture", Prentice Hall, New Jersey, 1989.Frey, D. and R. Adams, "!%@:: A Directory of Electronic MailAddressing and Networks", O’Reilly and Associates, Newton, MA,August 1989.Krol, E., "The Hitchhikers Guide to the Internet", RFC 1118,University of Illinois Urbana, September 1989.User Services Working Group [Page 12]LaQuey, T, Editor, "Users’ Directory of Computer Networks",Digital Press, Bedford, MA, 1990.Malkin, G., and A. Marine, "FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions", RFC 1206, FYI 4, FTP Software, Inc., SRI, February 1991.Postel, J., Editor, "IAB Official Protocol Standards", RFC 1140,Internet Activities Board, May 1990.Quarterman, J., "Matrix: Computer Networks and ConferencingSystems Worldwide", Digital Press, Bedford, MA, 1989.Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,USC/Information Sciences Institute, March 1990.Socolofsky, T., and C. Kale, "A TCP/IP Tutorial", RFC 1180, Spider Systems Limited, January 1991.Stevens, W., "UNIX Network Programming", ISBN 0-13-949876-1,Prentice Hall, Englewood Cliffs, NJ, 1990.Stine, R., Editor, "FYI on a Network Management Tool Catalog:Tools for Monitoring and Debugging TCP/IP Internets andInterconnected Devices" RFC 1147, FYI 2, Sparta, Inc., April 1990.12. References[1] Cerf, V., and K. Mills, "Explaining the Role of GOSIP", RFC 1169, IAB, NIST, August 1990.[2] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC1034, USC/Information Sciences Institute, November 1987.[3] Rose, M., and K. McCloghrie, "Structure and Identification ofManagement Information for TCP/IP-based Internets", RFC 1155,Performance Systems International, Hughes LAN Systems, May 1990.[4] McCloghrie, K., and M. Rose, "Management Information Base forNetwork Management of TCP/IP-based internets", RFC 1156, HughesLAN Systems, Performance Systems International, May 1990.[5] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A SimpleNetwork Management Protocol (SNMP)", RFC 1157, SNMP Research,Performance Systems International, Performance SystemsInternational, MIT Laboratory for Computer Science, May 1990.[6] Rose, M., Editor, "Management Information Base for NetworkUser Services Working Group [Page 13]Management of TCP/IP-based internets: MIB-II", RFC 1158,Performance Systems International, May 1990.[7] Postel, J., and J. Reynolds, "TELNET Protocol Specification", RFC 854, USC/Information Sciences Institute, May 1983.[8] Romkey, J., "A Nonstandard for Transmission of IP Datagrams over Serial Lines: SLIP", RFC 1055, June 1988.[9] Perkins, D., "The Point-to-Point Protocol: A Proposal for Multi- Protocol Transmission of Datagrams Over Point-to-Point Links",RFC 1171, CMU, July 1990.[10] Perkins, D., and R. Hobby, "The Point-to-Point Protocol (PPP)Initial Configuration Options", CMU, UC Davis, July 1990.[11] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,USC/Information Sciences Institute, March 1990.[12] Stine, R., Editor, "FYI on a Network Management Tool Catalog:Tools for Monitoring and Debugging TCP/IP Internets andInterconnected Devices" RFC 1147, FYI 2, Sparta, Inc., April1990.[13] Braden, R., Editor, "Requirements for Internet Hosts --Communication Layer", RFC 1122, Internet Engineering Task Force, October 1989.13. Security ConsiderationsSecurity issues are not discussed in this memo.User Services Working Group [Page 14]14. Authors’ AddressesGary Scott MalkinFTP Software, Inc.26 Princess StreetWakefield, MA 01880Phone: (617) 246-0900EMail: gmalkin@April N. MarineSRI InternationalNetwork Information Systems Center333 Ravenswood Avenue, EJ294Menlo Park, CA 94025Phone: (415) 859-5318EMail: APRIL@Joyce K. ReynoldsUSC/Information Sciences Institute4676 Admiralty WayMarina del Rey, CA 90292-6695Phone: (213) 822-1511EMail: jkrey@User Services Working Group [Page 15]。