File: rfc1127.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1123 lines) | stat: -rw-r--r-- 40,145 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123






Network Working Group                                       R. Braden
Request for Comments: 1127                                        ISI
                                                         October 1989


              A Perspective on the Host Requirements RFCs

Status of This Memo

   This RFC is for information only; it does not constitute a standard,
   draft standard, or proposed standard, and it does not define a
   protocol.  Distribution of this memo is unlimited.

Summary

   This RFC contains an informal summary of the discussions and
   conclusions of the IETF Working Group on Host Requirements while it
   was preparing the Host Requirements RFCs.  This summary has several
   purposes: (1) to inform the community of host protocol issues that
   need further work; (2) to preserve some history and context as a
   starting point for future revision efforts; and (3) to provide some
   insight into the results of the Host Requirements effort.

1.  INTRODUCTION

   A working group of the Internet Engineering Task Force (IETF) has
   recently completed and published a monumental standards document on
   software requirements for Internet hosts [RFC-1122, RFC-1123].  This
   document has been published as two RFC's: "Requirements for Internet
   Hosts -- Communication Layers", referred to here as "HR-CL", and
   "Requirements for Internet Hosts -- Application and Support",
   referred to here as "HR-AS".  Together, we refer to them as the Host
   Requirements RFCs, or "HR RFCs".

   Creation of the Host Requirements document required the dedicated
   efforts of about 20 Internet experts, with significant contributions
   from another 20.  The Host Requirements working group held 7 formal
   meetings over the past 20 months, and exchanged about 3 megabytes of
   electronic mail.  The HR RFCs went through approximate 20 distinct
   drafts.

   This group of people struggled with a broad range of issues in host
   implementations of the Internet protocols, attempting to reconcile
   theoretical and architectural concerns with the sometimes conflicting
   imperatives of the real world.  The present RFC recaps the results of
   this struggle, with the issues that were settled and those that
   remain for future work.  This exegesis has several goals:




Braden                                                          [Page 1]

RFC 1127           Perspective on Host Requirements         October 1989


   (1)  to give the Internet technical community some insight into the
        results of the host requirements effort;

   (2)  to inform the community of areas that need further work; and

   (3)  to preserve some history and context of the effort as a starting
        point for a future revision.

1.1  GOALS OF THE HOST REQUIREMENTS RFCs

   The basic purpose of the Host Requirements RFCs is to define the
   requirements for Internet host software.  However, the document goes
   far beyond a simple prescription of requirements, to include:

   (a)  a bibliography of the documents essential to an implementor;

   (b)  corrections and updates to the original standards RFC's;

   (c)  material to fill gaps in the previous specifications;

   (d)  limitations on implementation choices, where appropriate;

   (e)  clarification of important issues and the intent of the
        protocols; and

   (f)  documentation of known solutions to recurring problems as well
        as implementation hints.

   Broadly speaking, the Host Requirements working group started from
   the following goals for Internet host software:

   (1)  Interoperability

   (2)  Extensibility

   (3)  Functionality

   (4)  Efficiency

   (5)  Architectural Purity

   Of these, interoperability was clearly preeminent, while
   architectural purity had the lowest priority.  It is more difficult
   to assign relative importance to extensibility, functionality, and
   efficiency, as it varied from one topic to another.

   At a more technical level, the working group pursued a set of general
   goals that included the following:



Braden                                                          [Page 2]

RFC 1127           Perspective on Host Requirements         October 1989


   *    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.

   In addition to these general technical goals, the working group
   decided to discourage the use of certain protocol features: e.g., 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.

   The HR RFC tries to deal only with the software implementation, not
   with the way in which that software is configured and applied.  There
   are a number of requirements on Internet hosts that were omitted from
   the HR RFC as administrative or configuration issues.

   The HR RFCs contain many, many detailed requirements and
   clarifications that are straightforward and (almost) non-
   controversial.

   Indeed, many of these are simply restatements or reinforcement of
   requirements that are already explicit or implicit in the original
   standards RFC's.  Some more cynical members of the working group
   refer to these as "Read The Manual" provisions.  However, they were
   included in the HR RFCs because at least one implementation has



Braden                                                          [Page 3]

RFC 1127           Perspective on Host Requirements         October 1989


   failed to abide by these requirements.  In addition, many provisions
   of the HR RFCs are simply applications of Jon Postel's Robustness
   Principle [1.2.2 in either RFC].

   However, not all issues were so easy; the working group struggled
   with a number of deep and controversial technical issues.  Where the
   result was a reasonable consensus, then definite, firm
   recommendations and requirements resulted.  We list these settled
   issues in Section 2.  Section 2 also lists a number of areas where
   the HR RFCs fill gaping holes in the current specifications by giving
   extended discussions of particular issues.

   However, in some other cases the working group was unable to reach a
   crisp decision or even a reasonable consensus; we list these open
   issues in Section 3.  Future discussion is needed to ascertain which
   of these issues really do have "right answers", and which can
   reasonably be left as implementation choices.  Section 4 contains
   some other areas that the working group did not tackle but which need
   further work outside the context of the HR RFCs (although the outcome
   may be reflected in a future revision).  Finally, Appendix I lists
   specific issues for consideration by a future HR RFC revision effort,
   while Appendix II lists the issues that are relevant to a revision of
   the Gateway Requirements RFC.

   It should be noted that this categorization of issues is imperfect; a
   few issues appear (legitimately) in more than one category.

   For brevity, we do not attempt to define all the terminology or
   explain all the concepts mentioned here.  For those cases where
   further clarification is needed, we include (in square brackets)
   references to the corresponding sections of the HR RFCs.

2.  SETTLED ISSUES

   Here are the areas in which the Host Requirements working group was
   able to reach a consensus and take a definite stand.

   -    ARP Cache Management   [CL 2.3.2.1]

        Require a mechanism to flush out-of-date ARP cache entries.

   -    Queueing packets in ARP   [CL 2.3.2.2]

        Recommend that ARP queue unresolved packet(s) in the link layer.

   -    Ethernet/802.3 Interoperability   [CL 2.3.3]

        Impose interoperability requirements for Ethernet and IEEE 802.3



Braden                                                          [Page 4]

RFC 1127           Perspective on Host Requirements         October 1989


        encapsulation.

   -    Broadcast Storms   [CL 2.4, 3.2.2]

        Require many provisions to prevent broadcast storms.

        In particular, require that the link-layer driver pass a flag to
        the IP layer to indicate if a packet was received via a link-
        layer broadcast, and require that this flag be used by the IP
        layer.

   -    Bad IP addresses

        Include numerous provisions to discourage the use of bad IP
        addresses.

   -    Address Mask Replies   [CL 3.2.2.9]

        Discourage gratuitous ICMP Address Mask Reply messages.

   -    Type-of-Service

        Include various requirements on IP, transport, and application
        layers to make Type-of-Service (TOS) useful.

   -    Time-to-Live   [CL 3.2.1.7]

        Require that Time-to-Live (TTL) be configurable.

   -    Source Routing   [CL 3.2.1.8(e)]

        Require that host be able to act as originator or final
        destination of a source route.

   -    IP Multicasting   [CL 3.3.7]

        Encourage implementation of local IP multicasting.

   -    Reassembly Timeout   [CL 3.3.2]

        Require a fixed reassembly timeout.

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

        Require that an application on a multihomed host be able to
        either specify which local IP address to use for a new TCP
        connection or UDP request, or else leave the local address
        "wild" and let the IP layer pick one.



Braden                                                          [Page 5]

RFC 1127           Perspective on Host Requirements         October 1989


   -    TCP Performance   [CL 4.2.12.15, 4.2.3.1-4]

        Require TCP performance improvements.

   -    TCP Connection Robustness   [CL 4.2.3.5, 4.2.3.9]

        Encourage robustness of TCP connections.

   -    TCP Window Shrinking   [CL 4.2.2.16]

        Discourage the shrinking of TCP windows from the right.

   -    Dotted-Decimal Host Numbers   [AS 2.1]

        Recommend that applications be able to accept dotted-decimal
        host numbers in place of host names.

   -    Telnet End-of-Line   [AS 3.3.1]

        Include compatibility requirements for Telnet end-of-line.

   -    Minimal FTP   [AS 4.1.2.13]

        Enlarge the minimum FTP implementation.

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

        Recommend the use of long timeouts and of alternative addresses
        for multihomed hosts, to obtain robust mail delivery.

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

        Discourage the use of source routes for delivering mail.  (This
        was one of the few cases where the working group opted for the
        architecturally pure resolution of an issue.)

   -    Fully-Qualified Domain Names   [AS 5.2.18]

        Require the use of fully-qualified domain names in RFC-822
        addresses.

   -    Domain Name System Required   [AS 6.1.1]

        Require that hosts implement the Domain Name System (DNS).

   -    WKS Records Detracted   [AS 2.2, 5.2.12, 6.1.3.6]

        Recommend against using WKS records from DNS.



Braden                                                          [Page 6]

RFC 1127           Perspective on Host Requirements         October 1989


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

        Require that UDP be preferred over TCP for DNS queries.

   -    DNS Negative Caching  [AS 6.1.3.3]

        Recommend that DNS name servers and resolvers cache negative
        responses and temporary failures.

   Finally, here is a list of areas in which the HR RFCs provide
   extended discussion of issues that have been inadequately documented
   in the past.

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

        (Note that this topic is also one of the significant contentious
        issues; 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 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 1989


3.  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 1989


4.  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 route



Braden                                                          [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 experimentally



Braden                                                         [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 processed



Braden                                                         [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
   need future effort.

6.  REFERENCES

   [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.




Braden                                                         [Page 14]

RFC 1127           Perspective on Host Requirements         October 1989


APPENDIX I -- ISSUES FOR FUTURE REVISION

   In order to complete the HR RFCs, it was necessary to defer some
   technical issues.  These issues should be considered by the parties
   responsible for the first update of the HR RFCs.

   The issues pending at the time of publication are listed here, in
   order by protocol layer.

   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).

   Link Layer Issues:

   -    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



Braden                                                         [Page 15]

RFC 1127           Perspective on Host Requirements         October 1989


      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

      The HR RFCs takes the general approach that a host should ignore
      whatever it does not understand, so that possible future
      extensions -- e.g., new IP options or new ICMP message types --
      will cause minimum problems for existing hosts.  The result of
      this approach 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; it may sometimes be more useful
      to obtain an ICMP error message 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



Braden                                                         [Page 16]

RFC 1127           Perspective on Host Requirements         October 1989


      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

      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.






Braden                                                         [Page 17]

RFC 1127           Perspective on Host Requirements         October 1989


   -    Telnet LineMode Option

      This important new option is still experimental, but 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.




Braden                                                         [Page 18]

RFC 1127           Perspective on Host Requirements         October 1989


   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



Braden                                                         [Page 19]

RFC 1127           Perspective on Host Requirements         October 1989


      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: to process options in the order presented, or 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

   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
























Braden                                                         [Page 20]