RFC 1127

Perspective on the Host Requirements RFCs

📅 published October 1989, from ietf

RFC 1127: A Perspective on the Host Requirements RFCs 💖

okay bestie, let's get into it 🎀 this is RFC 1127 from the Network Working Group, written by R. Braden at ISI back in October 1989 ✨. it's Informational, so it's just here to inform, not a standard or a new protocol 🦋. the header doesn't list any Obsoletes or Updates lines, so there's nothing it's replacing or patching 💅

Status of This Memo 🧚

this one is for information only 🌸 it isn't a standard, a draft standard, or a proposed standard, and it doesn't define a protocol. distribution is unlimited 🌈

Summary ✨

this RFC is an informal recap of what the IETF Working Group on Host Requirements talked through and decided while it was putting together the Host Requirements RFCs 💅 it's got three main purposes:

  1. to tell the community about host protocol issues that still need work 🔥
  2. to save some history and context as a starting point for future revisions 📜
  3. to give some insight into what the Host Requirements effort actually produced 💜

1. INTRODUCTION 🦋

so, the IETF's Host Requirements working group just finished a huge standards document about the software Internet hosts need to have [RFC-1122, RFC-1123] 😭 it got published as two RFCs. the first is "Requirements for Internet Hosts -- Communication Layers", which we're calling "HR-CL". the second is "Requirements for Internet Hosts -- Application and Support", which is "HR-AS". together they're the Host Requirements RFCs, or "HR RFCs" for short 🎀

this took a LOT of work 🫶 about 20 Internet experts did the dedicated heavy lifting, with big contributions from another 20 people. the working group had 7 formal meetings over the past 20 months and swapped about 3 megabytes of email. the HR RFCs went through approximate 20 distinct drafts 🙈

this crew was wrestling with a huge range of issues in how hosts implement the Internet protocols. they were trying to make the theory and architecture work with the messy, sometimes conflicting needs of the real world 🌍 this RFC recaps how that struggle went, including what got settled and what's still open. the goals here are:

  1. to give the Internet technical community some insight into the results of the host requirements effort ✨
  2. to tell the community which areas need more work 🔥
  3. to preserve the history and context of the effort as a starting point for a future revision 🧚

1.1. GOALS OF THE HOST REQUIREMENTS RFCs 💅

the main job of the HR RFCs is to define requirements for Internet host software, but they're giving way more than a list of rules 👑 they also include:

  • (a) a bibliography of the documents an implementor really needs 📚
  • (b) corrections and updates to the original standards RFCs 🔧
  • (c) material that fills gaps in the earlier specifications 🧩
  • (d) limits on implementation choices, where that makes sense 🎀
  • (e) clarification of important issues and the intent behind the protocols 💜
  • (f) documentation of known fixes for recurring problems, plus implementation hints 💡

the broad goals the working group started from for Internet host software were:

  1. Interoperability 🫶
  2. Extensibility 🌈
  3. Functionality ✨
  4. Efficiency ⚡
  5. Architectural Purity 🏛️

interoperability was clearly the main priority, and architectural purity had the lowest priority 👑 it's harder to rank extensibility, functionality, and efficiency, because it changed depending on the topic 🙃

at a more technical level, the working group also aimed for a bunch of specific things, like:

  • Discourage hosts from unexpectedly acting as gateways. 🚧
  • Discourage the use of bad IP addresses. 🙅‍♀️
  • Eliminate broadcast storms. 🌪️
  • Discourage gratuitous Address Mask Reply messages. 🙄
  • Facilitate the use IP Type-of-Service for routing and queueing. 🚦
  • Encourage implementations of IP multicasting. 📡
  • Encourage TCP connection robustness. 🛡️
  • Encourage (mandate!) implementation of known TCP performance enhancements. 🏎️💨
  • Encourage user interfaces that support the full capabilities of the protocols. 🎨
  • Encourage more complete implementations of FTP. 📁
  • Encourage robust mail delivery 📬
  • Discourage the source-routing of mail in the Internet. 🙅
  • Encourage error logging. 🪵

on top of those, the group decided to discourage some protocol features 💀 like the IP Stream Id option, ICMP Information Request and Reply messages, the RFC-795 TOS mappings, WKS records in the Domain Name System, and FTP Page structure. it's giving "retire the old stuff" energy 🫠

the HR RFC only deals with the software itself, not how that software gets configured and used 🎀 a bunch of host requirements got left out on purpose because they're administrative or configuration issues 🗂️

the HR RFCs have a LOT of detailed requirements and clarifications that are pretty straightforward and (almost) totally uncontroversial 🥰 plenty of them just restate or reinforce things that were already explicit or implied in the original standards RFCs. some of the more cynical folks in the group call these "Read The Manual" provisions 📖😂 they still went in, though, because at least one implementation failed to follow them. a lot of other provisions are just Jon Postel's Robustness Principle in action [1.2.2 in either RFC] 👑

not everything was that easy, though 😤 the group wrestled with a bunch of deep, controversial technical issues. where they reached a reasonable consensus, they came out with firm recommendations and requirements, and we list those settled issues in Section 2 💖 Section 2 also covers the areas where the HR RFCs fill some seriously gaping holes in the current specs, with extended discussions of specific issues.

in other cases, the group couldn't land a clean decision or even a reasonable consensus. those open issues are in Section 3 🌪️ more discussion is needed to figure out which of them really have "right answers" and which can be left as implementation choices 🤔 Section 4 has other areas the group didn't tackle but that still need work outside the HR RFCs (the outcome might show up in a future revision though) 🔮 finally, Appendix I lists specific issues for a future HR RFC revision effort, and Appendix II lists the issues that matter for a revision of the Gateway Requirements RFC 🧚

ngl this categorization isn't perfect 🙈 a few issues legitimately show up in more than one category, and that's fine 🫶

for brevity, we're not going to define every term or explain every concept here 🫣 when something needs more clarification, we point to the matching sections of the HR RFCs in square brackets 📌

2. Settled Issues ✨

okay bestie, let's talk about the stuff the Host Requirements working group actually agreed on 💅 these were the areas where they reached consensus and took a definite stand, no drama lol 🫶

ARP Cache Management 🧹 [CL 2.3.2.1]

the group said ARP needs a way to flush out-of-date ARP cache entries. MUST have it, no cap 🔥

Queueing packets in ARP 📦 [CL 2.3.2.2]

they recommend that ARP queue unresolved packet(s) in the link layer. SHOULD be the move 💖

Ethernet/802.3 Interoperability 🔌 [CL 2.3.3]

hosts need to play nicely with each other for Ethernet and IEEE 802.3 encapsulation, so they get interoperability requirements. it's giving compatibility 🫶

Broadcast Storms 🌪️ [CL 2.4, 3.2.2]

broadcast storms are NOT the vibe, so the group required many provisions to prevent them 😭

one big one: the link-layer driver MUST pass a flag up to the IP layer to say whether a packet came in via a link-layer broadcast, and the IP layer MUST use that flag. it's lowkey genius 🧚

Bad IP addresses 🚫

they included numerous provisions to discourage the use of bad IP addresses. bad addresses are a no from me 🙅‍♀️

Address Mask Replies 🎭 [CL 3.2.2.9]

gratuitous ICMP Address Mask Reply messages are discouraged. nobody wants unsolicited replies showing up uninvited 💀

Type-of-Service 🎀

there are various requirements on IP, transport, and application layers so that Type-of-Service (TOS) actually does something useful. main character energy for TOS ✨

Time-to-Live ⏳ [CL 3.2.1.7]

Time-to-Live (TTL) MUST be configurable. no hardcoding that, bestie 🙈

Source Routing 🗺️ [CL 3.2.1.8(e)]

hosts MUST be able to act as the originator or the final destination of a source route. iconic 👑

IP Multicasting 📡 [CL 3.3.7]

local IP multicasting is encouraged to be implemented. it's giving "yes please" 🌈

Reassembly Timeout ⌛ [CL 3.3.2]

a fixed reassembly timeout MUST be used. consistency is everything 💜

Choosing a Source Address 🏠 [CL 3.3.4.3, 3.4, 4.1.3.5, 4.2.3.7]

on a multihomed host, an application MUST be able to either specify which local IP address to use for a new TCP connection or UDP request, OR leave the local address "wild" and let the IP layer pick one. so much choice, I'm obsessed 😭🫶

TCP Performance 🚀 [CL 4.2.12.15, 4.2.3.1-4]

TCP performance improvements are required. the group said TCP MUST get these upgrades, periodt 💅

TCP Connection Robustness 🛡️ [CL 4.2.3.5, 4.2.3.9]

robustness of TCP connections is encouraged. protect the connection, protect the vibe 🫶

TCP Window Shrinking 🪟 [CL 4.2.2.16]

shrinking TCP windows from the right is discouraged. nobody likes a window that just keeps getting smaller 🙃

Dotted-Decimal Host Numbers 🔢 [AS 2.1]

applications SHOULD be able to accept dotted-decimal host numbers in place of host names. numbers are valid, babe 💖

Telnet End-of-Line ↩️ [AS 3.3.1]

there are compatibility requirements for Telnet end-of-line. the group wanted everyone to get along here too 🌸

Minimal FTP 📁 [AS 4.1.2.13]

the minimum FTP implementation gets enlarged. bigger minimum, bigger energy 💪

Robust Mail Delivery 📬 [AS 5.3.2, 5.3.4, 6.1.3.4]

for multihomed hosts, long timeouts and alternative addresses are recommended so mail actually gets where it's going. we love a reliable delivery 🦋

Source-Routing of Mail 🚫🗺️ [AS 5.2.6, 5.2.16, 5.2.19]

the use of source routes for delivering mail is discouraged. this was one of the few times the group picked the architecturally pure option, and I respect the commitment 👑 (ngl, a stan moment)

Fully-Qualified Domain Names 🏷️ [AS 5.2.18]

fully-qualified domain names MUST be used in RFC-822 addresses. no shortcuts, full name or nothing 💅

Domain Name System Required 🌐 [AS 6.1.1]

hosts MUST implement the Domain Name System (DNS). non-negotiable, it's the foundation 🫶

WKS Records Detracted 🙅‍♀️ [AS 2.2, 5.2.12, 6.1.3.6]

using WKS records from DNS is NOT recommended. they're just not it 💀

UDP Preferred for DNS Queries 📨 [AS 6.1.2.4, 6.1.3.2]

UDP MUST be preferred over TCP for DNS queries. speed is the whole point 🔥

DNS Negative Caching 🧠 [AS 6.1.3.3]

DNS name servers and resolvers are recommended to cache negative responses and temporary failures. remember the no's so you don't keep asking 🙈

Finally, the HR RFCs give extended discussion to areas that were inadequately documented in the past. these are the topics they really dug into 🔍

  • ARP cache handling 🧹 [CL 2.3.2.1]
  • Trailer encapsulation 🎁 [CL 2.3.1]
  • Dead gateway detection algorithms 💀 [CL 3.3.1.4]
  • IP multihoming models 🏠 [CL 3.3.4]

(this one is ALSO a major contentious issue, see the next section 👀)

  • Maximum transmission unit (MTU and transport-layer maximum-segment size (MSS) issues 📏 [CL 3.3.2, 3.3.3, 3.4, 4.1.4, 4.2.2.6]
  • TCP silly-window syndrome (SWS) avoidance algorithms 🪟 [CL 4.2.3.3, 4.2.3.4]
  • Telnet end-of-line issues ↩️ [AS 3.3.1]
  • 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 were also some areas where the group tried to write up a more extended discussion but didn't fully pull it off. one example is error logging (see Appendix I below) 📝

3. Open Issues 🥺

some issues were so heated that the working group couldn't reach consensus at all 😭 in each case, some people spoke for MUST or SHOULD, while others argued just as passionately for MUST NOT or SHOULD NOT. so the HR RFCs summarize the different viewpoints but take no stand, and the matching requirements are written as MAY or OPTIONAL. the most notorious ones are below 👀

  • 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 batch of controversial issues where the HR RFCs did take a compromise stand: the disputed functions are allowed, but their use is circumscribed. in lots of these cases, a significant group of people wanted the feature banned completely 🙅‍♀️

  • 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]

4. OTHER FUTURE WORK ✨

okay so bestie, this is the to-do list 📝 the HR working group couldn't finish everything, so they wrote down all the stuff that still needs future effort. it's giving homework for future us 🦋 no cap, some of these are lowkey iconic.

General Issues

(1) Host Initialization Procedures

okay so when a host boots up or initializes, it needs some network config info before it can talk to anyone 🫶 like its own IP address(es) and address mask(s). for a diskless workstation, getting this info is literally part of the booting process 💻

the ICMP Address Mask messages and RARP (Reverse ARP) each give you one piece of the config puzzle 🧩. the working group felt that piecemeal solutions are a mistake ❌, and that a comprehensive approach would give you one uniform mechanism to provide all the required configuration info at once ✨. so the HR working group recommends that a new working group get set up to develop a unified approach to system initialization 👑

(2) Configuration Options

vendors, users, and network admins all want host software that's "plug-and-play" 🔌. unfortunately the working group was often forced to require extra configuration parameters to satisfy interoperability, functionality, and/or efficiency needs [1.2.4 in either RFC] 😭. they were fully aware of the drawbacks of config parameters, but based on extensive experience with existing implementations, they felt the flexibility was sometimes more important than installation simplicity 💅

some config parameters are forced for interoperability with earlier, incorrect implementations 💀. very little can be done about this, although retiring the offending systems will gradually solve it 🌸. still, it would be desirable to re-examine the other required configuration options, to try to find ways to eliminate some of them 🎀

(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 route 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 even further 😵‍💫

the algorithms for maintaining the ARP cache need to be studied and experimented with, so we can create more complete and explicit algorithms and requirements 🧪

(3) FDDI Bit-order in MAC addresses

on IEEE 802.3 or 802.4 LAN's, the MAC address in the header uses the same bit-ordering as when the address is sent as data 👍. but on 802.5 and FDDI networks, the MAC address in the header has 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 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 being able to detect when its first-hop gateway has failed 🚨. the early TCP/IP experimentation was based on the ARPANET, which gave explicit notification of gateway failure, so dead gateway detection algorithms weren't really considered at that time 🕰️. the very general guidelines presented by Dave Clark [RFC-816] are inadequate for implementors 🙅‍♀️. the first attempt at applying them was universal gateway pinging by TOPS-20 systems, which quickly proved to be a major generator of ARPANET traffic and got 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) 👀. so the HR working group was faced with an absence of documented 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 experimentally 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 their adoption 🚧. code written to use these options has never been tested 🫣. this work should be carried forward, because 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 😮‍💨

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 for 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's 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 processed 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

the original quote is the star of this one, so here it is in full 💅

"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 does need to distinguish files from directories 📁. up to now, these interfaces have relied on a bug in many FTP servers, which 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 the one 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 🧜‍♀️.

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 summarized the results of the Host Requirements Working Group, and listed a set of issues in Internet host protocols that need future effort 💖

6. REFERENCES 📚

okay bestie, here's the reading list 🤓 these are all the RFCs and memos this one is built on

  • [RFC-1122] Braden, R., Editor, "Requirements for Internet Hosts -- Communications Layers", RFC 1122, IETF Host Requirements Working Group, October 1989.
  • [RFC-1123] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", RFC 1123, IETF Host Requirements Working Group, October 1989.
  • [RFC-1009] Braden, R., and J. Postel, "Requirements for Internet Gateways", RFC 1009, USC/Information Sciences Institute, June 1987.
  • [RFC-1101] Mockapetris, P., "DNS Encoding of Network Names and Other Types", RFC 1101, USC/Information Sciences Institute, April 1989.
  • [RFC-1063] Mogul, J., C. Kent, C. Partridge, and K. McCloghrie, "IP MTU Discovery Options", RFC-1063, DEC, BBN, & TWG, July 1988.
  • [RFC-816] Clark, D., "Fault Isolation and Recovery", RFC-816, MIT, July 1982.
  • [CLynn] Lynn, C., "Use of TCP Reset to Convey Error Diagnostics", Internal Memo, BBN, December 1988.
  • [Lekashman] Message to ietf-hosts mailing list from John Lekashman, 14 September 1988.
  • [Matthews] Message to Postel from Jim Matthews, 3 August 1989.

APPENDIX I -- ISSUES FOR FUTURE REVISION 🔮

okay so, to finish the HR RFCs, the group had to put some technical issues on the back burner 🥺 these are the ones still pending at publication, sorted by protocol layer 🎀

The people responsible for the first update of the HR RFCs should consider these issues.

General Issue

Error Logging

The working group felt that more complete and explicit guidance on error logging procedures is needed than is presently contained in Section 1.2.3 (both HR RFCs). 📝

Stolen IP Address

How should a host react when it detects through ARP traffic that some other host has "stolen" its IP address? 😱

IP Layer Issues

"Raw Mode" Interface

HR-CL could define an optional "raw mode" interface from the application layer to IP. 🧃

Rational Fragmentation

When a host performs intentional fragmentation, it should make the first fragment as large as possible (this same requirement should be placed on gateways). ✂️

Interaction of Multiple Options

HR-CL does not give specific rules for the interactions of multiple options in the same IP header. This issue was generally deferred to a revision of the Gateway Requirements RFC. However, this issue might be revisited for hosts. 🤔

ICMP Error for Source-Routed Packet

It was suggested that when a source-routed packet arrives with an error, any ICMP error message should be sent with the corresponding return route. This assumes that the ICMP error message is more likely to be delivered successfully with the source route than without it. 🛣️

"Strong" IP Options and ICMP Types

this one is giving drama 🎭 The HR RFCs take the general approach that a host should ignore whatever it does not understand. That way, possible future extensions (e.g., new IP options or new ICMP message types) cause minimum problems for existing hosts. The downside is that when new facilities are used with old hosts, a "black hole" can result. Several people have suggested that this is not always what is wanted. Sometimes it may be more useful to get an ICMP error message back from the old host. 🕳️ To quote Jeremey Siegel:

"The basic premise is that if an option is to have any real meaning at all within an '[upward] compatible' environment, it must be known whether or not the option actually carries its meaning. An absurd analogy might be programming languages: I could make a compiler which simply ignored unknown sorts of statements, thereby allowing for future expansion of the language." "Right now, there are four "classes" of options; only two are defined. Take one of the other classes, and define it such that any options in that class, if unrecognized, cause an ICMP error message. Thus anyone who wants to propose a "strong" option (one which requires full participation by all systems involved to operate correctly) can assign it to that class. Options in the current classes may still be passed through if they are unknown; only "weak" options will be assigned to these classes in the future."

Network Mask

As explained in HR-CL [CL 3.1.2.3], we believe that a possible future transition for the interpretation of IP addresses may be eased if hosts always treat an IP address as an indivisible 32-bit number. However, there are various circumstances where a host has to distinguish its own network number. Charlie Lynn has suggested that indivisibility can be retained if a host is configured with both an address mask (indicating subnetting) and a network mask (with network but not subnet bits). 🎭

WhoAmI Query

The following requirement is needed: for a multihomed host, a UDP-based application should (must?) be able to query the communication layers to obtain a list of all local IP addresses for the host. 📡

New Destination Unreachable codes

For each of the new ICMP Destination Unreachable codes defined in HR-CL [CL 3.2.2.1], it should be documented whether the error is "soft" or "hard". 🏷️

ICMP Error Schizophrenia

this is a whole contradiction, bestie 💀 Section 3.3.8 of HR-CL requires a host to send ICMP error messages. Yet in nearly all individual cases, the specific requirements say that errors are to be silently ignored. The working group recognized this contradiction but was unwilling to resolve it.

At every choice point, the working group opted towards a requirement that would avoid broadcast storms. For example, (1) ICMP errors cannot be sent for broadcasts, and also (2) individual errors are to be silently ignored. This is redundant. Either provision (1) or (2) alone, if followed, should eliminate broadcast storms. The general area of responses to errors and broadcast storms could be reassessed and the individual decisions reviewed. 🌪️

Transport-Layer Requirements

Delayed ACK Definition

A more precise and complete definition of the conditions for delaying a TCP ACK segment may be desirable; see Section 4.2.3.2 of HR-CL. ⏳

Telnet Requirements

Flushing Output

The DISCUSSION in Section 3.2.4 of HR-AS concerns three possible ways for a User Telnet to flush output. It would be helpful for users and implementers if one of these could be recommended over the others. However, when the working group discussed the matter, there seemed to be compelling arguments for each choice. This issue needs more study. 🧐

Telnet LineMode Option

This important new option is still experimental. When it becomes a standard, implementation should become recommended or required. 🌟

FTP Requirements

Reply Codes

A number of problems have been raised with FTP reply codes. 🙈

(a) Access Control Failures

Note that a 550 message is used to indicate access control problems for a read-type operation (e.g., RETR, RNFR), while a 553 message is used for the same purpose for a write-type operation (e.g., STOR, STOU, RNTO).

LIST, NLST, and STAT may fail with a 550 reply due to an access control violation.

MKD should fail with a 553 reply if a directory already exists with the same name.

(b) Directory Operations (RFC-959 Appendix II)

An RMD may result in a 450 reply if the directory is busy.

Many of the reply codes shown in the text of Appendix II are wrong. A positive completion for CWD should be 250. The 521 code shown for MKD should be 553 (see above), while the 431 shown for CWD should be a 550.

(c) HELP and SITE Commands

The positive completion reply to a HELP command should be code 214.

HELP or SITE with an invalid argument should return a 504 reply.

Bidirectional FTP

The FTP specification allows an implementation in which data transfer takes place in both directions simultaneously, although few if any implementations support this. Perhaps HR-AS should take a stand for or against this. ↔️

SMTP Requirements

Offline SEND

Some on the working group felt that the SMTP SEND command, intended to display a message immediately on the recipient's terminal, should produce an error message if delivery must be deferred. 📬

Header-like Fields

John Klensin proposed:

"Header-like fields whose keywords do not conform to RFC822 are strongly discouraged; gateways SHOULD filter them out or place them into the message body. If, however, they are not removed, Internet hosts not acting as gateways SHOULD NOT utilize or inspect them. Hence address-like subfields of those fields SHOULD NOT be altered by the gateway."

Syntax of Received: Line

The precise syntax of a revised Received: line (see Section 5.2.8 of HR-AS) could be given. An unresolved question concerned the use of "localhost" rather than a fully-qualified domain name in the FROM field of a Received: line. Finally, new syntax was proposed for the Message Id field. 🧾

Appendix II -- Gateway Issues 🚪

The working group identified a set of issues that should be considered when the Gateway Requirements RFC [RFC-1009] ("GR RFC") is revised. 💅

All-Subnets Broadcast

This facility is not currently widely implemented, and HR-CL warns users of this fact. The GR RFC should take a stand on whether or not gateways ought to implement the necessary routing. 📡

Rational Fragmentation

When a gateway performs intentional fragmentation, it should make the first fragment as large as possible. 🧩

Illegal Source Address

It has been suggested that a gateway should not forward a packet containing an illegal IP source address, e.g., zero. 🚫

Option Processing

Specific rules should be given for the order of processing multiple options in the same IP header. Two approaches have been used. One is to process options in the order presented. The other is to parse them all and then process them in some "canonical" order. The legality should also be defined for using broadcast or multicast addresses in IP options that include IP addresses. 🔢

Security Considerations 🔐

the security section, bestie, it's serious business 🚨

A future revision of the Host Requirements RFCs should incorporate a more complete discussion of security issues at all layers.

Author's Address 💌

Robert Braden
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695

Phone: (213) 822 1511

EMail: Braden@ISI.EDU
📦 where this page comes from