📄 rfc1127.txt
字号:
- Telnet interrupt/SYNCH usage [AS 3.2.4] - FTP restart facility [AS 4.1.3.4] - DNS efficiency issues [AS 6.1.3.3] - DNS user interface: aliases and search lists [AS 6.1.4.3] There are some other areas where the working group tried to produce a more extended discussion but was not totally successful; one example is error logging (see Appendix I below).Braden [Page 7] RFC 1127 Perspective on Host Requirements October 19893. OPEN ISSUES For some issues, the disagreement was so serious that the working group was unable to reach a consensus. In each case, some spoke for MUST or SHOULD, while others spoke with equal fervor for MUST NOT or SHOULD NOT. As a result, the HR RFCs try to summarize the differing viewpoints but take no stand; the corresponding requirements are given as MAY or OPTIONAL. The most notorious of these contentious issues are as follows. - Hosts forwarding source-routed datagrams, even though the hosts are not otherwise acting as gateways [CL 3.3.5] - The multihoming model [CL 3.3.4] - ICMP Echo Requests to a broadcast or multicast address [CL 3.2.2.6] - Host-only route caching [CL 3.3.1.3] - Host wiretapping routing protocols [CL 3.3.1.4] - TCP sending an ACK when it receives a segment that appears to be out-of-order [CL 4.2.2.21] There was another set of controversial issues for which the HR RFCs did take a compromise stand, to allow the disputed functions but circumscribe their use. In many of these cases, there were one or more significant voices for banning the feature altogether. - Host acting as gateways [CL 3.1] - Trailer encapsulation [CL 2.3.1] - Delayed TCP acknowledgments [CL 4.2.3.2] - TCP Keep-alives [CL 4.2.3.6] - Ignoring UDP checksums [CL 4.1.3.4] - Telnet Go-Aheads [AS 3.2.2] - Allowing 8-bit data in Telnet NVT mode [AS 3.2.5]Braden [Page 8] RFC 1127 Perspective on Host Requirements October 19894. OTHER FUTURE WORK General Issues: (1) Host Initialization Procedures When a host system boots or otherwise initializes, it needs certain network configuration information in order to communicate; e.g., its own IP address(es) and address mask(s). In the case of a diskless workstation, obtaining this information is an essential part of the booting process. The ICMP Address Mask messages and the RARP (Reverse ARP) protocol each provide individual pieces of configuration information. The working group felt that such piecemeal solutions are a mistake, and that a comprehensive approach to initialization would result in a uniform mechanism to provide all the required configuration information at once. The HR working group recommends that a new working group be established to develop a unified approach to system initialization. (2) Configuration Options Vendors, users, and network administrators all want host software that is "plug-and-play". Unfortunately, the working group was often forced to require additional configuration parameters to satisfy interoperability, functionality, and/or efficiency needs [1.2.4 in either RFC]. The working group was fully aware of the drawbacks of configuration parameters, but based upon extensive experience with existing implementations, it felt that the flexibility was sometimes more important than installation simplicity. Some of the configuration parameters are forced for interoperability with earlier, incorrect implementations. Very little can be done to ease this problem, although retirement of the offending systems will gradually solve it. However, it would be desirable to re-examine the other required configuration options, in an attempt to develop ways to eliminate some of them. Link-Layer Issues: (2) ARP Cache Maintenance "Proxy ARP" is a link-layer mechanism for IP routing, and its use results in difficult problems in managing the ARP cache. Even without proxy ARP, the management dynamics of the IP routeBraden [Page 9] RFC 1127 Perspective on Host Requirements October 1989 cache interact in subtle ways with transport-layer dynamics; introducing routing via proxy ARP brings a third protocol layer into the problem, complicating the inter-layer dynamics still further. The algorithms for maintaining the ARP cache need to be studied and experimented with, to create more complete and explicit algorithms and requirements. (3) FDDI Bit-order in MAC addresses On IEEE 802.3 or 802.4 LAN, the MAC address in the header uses the same bit-ordering as transmission of the address as data. On 802.5 and FDDI networks, however, the MAC address in the header is in a different bit-ordering from the equivalent 6 bytes sent as data. This will make it hard to do MAC-level bridging between FDDI and 802.3 LAN's, for example, although gateways (IP routers) can still be used. The working group concluded that this is a serious but subtle problem with no obvious fix, and that resolving it was beyond the scope of the HR working group. IP-Layer Issues (4) Dead Gateway Detection A fundamental requirement for a host is to be able to detect when the first-hop gateway has failed. The early TCP/IP experimentation was based on the ARPANET, which provided explicit notification of gateway failure; as a result, dead gateway detection algorithms were not much considered at that time. The very general guidelines presented by Dave Clark [RFC-816] are inadequate for implementors. The first attempt at applying these guidelines was the introduction of universal gateway pinging by TOPS-20 systems; this quickly proved to be a major generator of ARPANET traffic, and was squelched. The most widely used implementation of the Internet protocols, 4.2BSD, solved the problem in an extra-architectural manner, by letting the host wiretap the gateway routing protocol (RIP). As a result of this history, the HR working group was faced with an absence of documentated techniques that a host conforming to the Internet architecture could use to detect dead gateways. After extensive discussion, the working group agreed on the outline of an appropriate algorithm. A detailed algorithm was in fact written down, to validate the discussion in the HR RFCs. This algorithm, or a better one, should be tried experimentallyBraden [Page 10] RFC 1127 Perspective on Host Requirements October 1989 and documented in a new RFC. (5) Gateway Discovery A host needs to discover the IP addresses of gateways on its connected networks. One approach, begun but not finished by members of the HR working group, would be to define a new pair of ICMP query messages for gateway discovery. In the future, gateway discovery should be considered as part of the complete host initialization problem. (6) MTU Discovery Members of the HR working group designed IP options that a host could use to discover the minimum MTU of a particular Internet path [RFC-1063]. To be useful, the Probe MTU options would have to be implemented in all gateways, which is an obstacle to its adoption. Code written to use these options has never been tested. This work should be carried forward; an effective MTU choice will become increasingly important for efficient Internet service. (7) Routing Advice from Gateways A working group member produced a draft specification for ICMP messages a host could use to ask gateways for routing advice [Lekashman]. While this is not of such pressing importance as the issues listed previously, it deserves further consideration and perhaps experimentation. (8) Dynamic TTL Discovery Serious connectivity problems have resulted from host software that has too small a TTL value built into the code. HR-CL specifies that TTL values must be configurable, to allow TTL to be increased if required for communication in a future Internet; conformance with this requirement would solve the current problems. However, configurable parameters are an operational headache, so it has been suggested that a host could have an algorithm to determine the TTL ("Internet diameter") dynamically. Several algorithms have been suggested, but considerably more work would be required to validate them. This is a lower-priority problem than issues (4)-(6). (9) Dynamic Discovery of Reassembly Timeout Time The maximum time for retaining a partially-reassembled datagram is another parameter that creates a potential operational headache.Braden [Page 11] RFC 1127 Perspective on Host Requirements October 1989 An appropriate reassembly timeout value must balance available reassembly buffer space against reliable reassembly. The best value thus may depend upon the system and upon subtle delay properties (delay dispersion) of the Internet. Again, dynamic discovery could be desirable. (10) Type-of-Service Routing in Hosts As pointed out previously, the HR RFCs contain a number of provisions designed to make Type-of-Service (TOS) useful. This includes the suggestion that the route cache should have a place or specifying the TOS of a particular route. However, host algorithms for using TOS specifications need to be developed and documented. (11) Using Subnets An RFC is needed to provide a thorough explanation of the implications of subnetting for Internet protocols and for network administration. Transport-Layer Issues: (12) RST Message It has been proposed that TCP RST (Reset) segments can contain text to provide an explicit explanation of the reason for the particular RST. A proposal has been drafted [CLynn]. (13) Performance Algorithms HR-CL contains a number of requirements on TCP performance algorithms; Van Jacobson's slow start and congestion avoidance, Karn's algorithm, Nagle's algorithm, and SWS prevention at the sender and receiver. Implementors of new TCPs really need more guidance than could possibly be included in the HR RFCs. The working group suggested that an RFC on TCP performance is needed, to describe each of these issues more deeply and especially to explain how they fit together. Another issue raised by the HR RFCs is the need for validation (or rejection) of Van Jacobson's fast retransmit algorithm. Application-Layer Issues: (14) Proposed FTP extensions A number of minor extensions proposed for FTP should be processedBraden [Page 12] RFC 1127 Perspective on Host Requirements October 1989 and accepted or rejected. We are aware of the following proposals: (a) Atomic Store Command The FTP specification leaves undefined the disposition of a partial file created when an FTP session fails during a store operation. It was suggested that this ambiguity could be resolved by defining a new store command, Store Atomic (STOA). The receiver would delete the partial file if the transfer failed before the final data-complete reply had been sent. This assumes the use of a transfer mode (e.g., block) in which end-of-file can be distinguished from TCP connection failure, of course. (b) NDIR Command "NDIR would be a directories-only analogue to the NLST command. Upon receiving an NDIR command an FTP server would return a list of the subdirectories to the specified directory or file group; or of the current directory if no argument was sent. ... The existing NLST command allows user FTPs to implement user-interface niceties such as a "multiple get" command. It also allows a selective (as opposed to generative) file-naming user interface: the user can pick the desired file out of a list instead of typing its name." [Matthews] However, the interface needs to distinguish files from directories. Up to now, such interfaces have relied on a bug in many FTP servers, which have included directory names in the list returned by NLST. As hosts come into conformance with HR-AS, we need an NDIR command to return directory names. (c) Adaptive Compression It has been suggested that a sophisticated adaptive data compression algorithm, like that provided by the Unix "compress" command, should be added as an alternative FTP transfer mode. (15) SMTP: Global Mail Addressing While writing requirements for electronic mail, the working group was urged to set rules for SMTP and RFC-822 that would be universal, applicable not only to the Internet environment but also to the other mail environments that use one or both of these protocols. The working group chose to ignore this Siren call, and instead limit the HR RFC to requirements specific to the Internet.Braden [Page 13] RFC 1127 Perspective on Host Requirements October 1989 However, the networking world would certainly benefit from some global agreements on mail routing. Strong passions are lurking here. (16) DNS: Fully Replacing hosts.txt As noted in HR-AS [AS 6.1.3.8], the DNS does not yet incorporate all the potentially-useful information included in the DDN NIC's hosts.txt file. The DNS should be expanded to cover the hosts.txt information. RFC-1101 [RFC-1101] is a step in the right direction, but more work is needed.5. SUMMARY We have summarized the results of the Host Requirements Working Group, and listed a set of issues in Internet host protocols that⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -