--- 1/draft-ietf-2000-issue-02.txt 2007-12-18 18:35:07.000000000 +0100 +++ 2/draft-ietf-2000-issue-03.txt 2007-12-18 18:35:07.000000000 +0100 @@ -1,15 +1,13 @@ - Network Working Group Philip J. Nesser II - Editor -draft-ietf-2000-issue-02.txt Nesser & Nesser Consulting - The Internet and the Millenium Problem (Year 2000) +draft-ietf-2000-issue-03.txt Nesser & Nesser Consulting + The Internet and the Millennium Problem (Year 2000) Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by @@ -19,725 +17,9146 @@ Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract The Year 2000 Working Group(WG) has conducted an investigation into -the millenium problem as it regards Internet related protocols. -This investigation only targeted the protocols as documented in the -Request For Comments Series (RFCs). This investigation discovered -little reason for concern with regards to the functionality of the -protocols. A few minor cases of older implementations still using -two digit years (ala RFC 850) were discovered, but almost all -Internet protocols were given a clean bill of health. Several cases -of ''period'' problems were discussed where a time field would ''roll -over'' as the size of field was reached. In particular, there are -several protocols, which have 32 bit, signed integer representations -of the number of seconds since January 1, 1970 which will turn -negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols -will be effected by such problems have been notified so that new -revisions will remove this limitation. +the millennium problem as it regards Internet related protocols. This +investigation only targeted the protocols as documented in the Request +For Comments Series (RFCs). This investigation discovered little +reason for concern with regards to the functionality of the protocols. +A few minor cases of older implementations still using two digit years +(ala RFC 850) were discovered, but almost all Internet protocols were +given a clean bill of health. Several cases of "period" problems were +discovered, where a time field would "roll over" as the size of field +was reached. In particular, there are several protocols, which have +32 bit, signed integer representations of the number of seconds since +January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT +2038. Areas whose protocols will be effected by such problems have +been notified so that new revisions will remove this limitation. -1.0 Introduction +1. Introduction According to the trade press billions of dollars will be spend the -upcoming three years on the year 2000 problem, also called the -millenium problem (though the third millenium will only start in -2001). This problem consists of the fact that many software packages -and some protocols use a two-digit field for the year in a date -field. Most of the problems seem to be in administrative and -financial programs, or in the hardcoded microcomputers found in -electronic equipment. A lot of organizations are now starting to -make an inventory of which software and tools they use will suffer -from the millenium problem. +upcoming years on the year 2000 problem, also called the millennium +problem (though the third millennium will really start in 2001). This +problem consists of the fact that many software packages and some +protocols use a two-digit field for the year in a date field. Most of +the problems seem to be in administrative and financial programs, or +in the hardcoded microcomputers found in electronic equipment. A lot +of organizations are now starting to make an inventory of which +software and tools they use will suffer from the millennium problem. With the increasing popularity of the Internet, more and more -organizations start to use the Internet as a serious business tool. -This means that most organizations will want to analyze the millenium -problems due to the use of Internet protocols and popular Internet -software. In the trade press the first articles suggest that the -Internet will collapse at midnight the 31st of December 1999. +organizations use the Internet as a serious business tool. This means +that most organizations will want to analyze the millennium problems +due to the use of Internet protocols and popular Internet software. In +the trade press the first articles suggest that the Internet will +collapse at midnight the 31st of December 1999. -To counter these suggestions (that are obviously wrong) and to avoid -that all over the Internet people will redo the same inventory over and -over again the WG is to make an inventory of all important Internet -protocols and their most popular implementations with respect to the -millenium problem. Only software and protocols directly related to the -Internet will be considered. +To counter these suggestions, and to avoid having countless companies +redo the same investigation, this effort was undertaken by the IETF. +The Year 2000 WG has made an inventory of all-important Internet +protocols that have been documented in the Request for Comments (RFC) +series. Only protocols directly related to the Internet will be +considered. The editor of this document would like to acknowledge the critical contributions of the follow for direct performance of research and the provision of text: Alex Latzko, Robert Elz, Erik Huizer, Gillian Greenwood, Barbara Jennings, R.E. (Robert) Moore, David Mills, Lynn -Kubinec, Michael Patton, Chris Newman, Erik-Jan Bos, Paul Hoffman, -and Rick H. Wesson. The pace with which this group has operated has -only been achievable by the intimate familiarity of the contributors -with the protocols and ready access to the collective knowledge of the +Kubinec, Michael Patton, Chris Newman, Erik-Jan Bos, Paul Hoffman, and +Rick H. Wesson. The pace with which this group has operated has only +been achievable by the intimate familiarity of the contributors with +the protocols and ready access to the collective knowledge of the IETF. -Disclaimer +2. Disclaimer -This RFC is not complete. It is an effort to analyze the Y2K impact on -hundreds of protocols but is likely to have missed some protocols and -misunderstood others. Organizations should not attempt to claim any -legitimacy or approval for any particular protocol based on this +This RFC is not complete. It is an effort to analyze the Y2K impact +on hundreds of protocols but is likely to have missed some protocols +and misunderstood others. Organizations should not attempt to claim +any legitimacy or approval for any particular protocol based on this document. The efforts have concentrated on the identification of potential problems, rather than solutions to any of the problems that have been identified. Any proposed solutions are only that: proposed. A formal engineering review should take place before any solution is adopted. -Methodology +It should also be noted that the research was performd on RFCs 1 +through 2128. At that time the IESG was charted with not allowing +any new RFCs to be published that had any Year 2000 issues. Since +that cutoff time there has been work to correct issues discovered by +this Working Group. In particular, RWhois as documented by RFC 1714 +has been updated to fix the problems found. RFC 2167 now documents +a fixed version of the RWhois protocol. The work of this group was +to look backwards, and hence new RFC's which supplant the old are +expected to make the information in this RFC obsolete. The work of +this group will truly be complete when this document is completely +obsolete. + +A number of people have suggested looking into other "special" dates. +For example, the first leap year, the first "double digit" day +(January 10, 2000), January 1, 2001, etc. There is not one place +where days have been used in the protocols defined by the RFC series +so there is little reason to believe that any of these special dates +will have any impact. + +3. Summary of Year 2000 Problems + +Here is a brief description of all the Millenium issues discovered +in the course of this research. Note that many of the RFCs are +unclear on the issue. They mandate the use of UTCTime but do not +specify whether the two-digit or four-digit year representation +should be used. + +3.1 "Directory Services" + + rfc1274.txt - References UTC date/time + rfc1276.txt - References UTC date/time for version control. + rfc1488.txt - References UTC Time as printable strings. + rfc1608.txt - Refers to uTCTimeSyntax + rfc1609.txt - Refers to uTCTimeSyntax + rfc1778.txt - Refers to uTCTimeSyntax + +3.2 "Information Services and File Transfer" + +HTTP 1.1, as defined in RFC 2068, requires all newly generated date +stamps to conform to RFC 1123 date formats which are Year 2000 +compliant, but it also requires acceptance of the older non-compliant +RFC850 formats. Some specific recommendations have been passed to +the HTTP WG. + +HTML 2.0, as defined in RFC 1866, could allow a very subtle Year 2000 +problem, but once again this recommendation has been passed on the +HTML WG. + +RFC 1778 on String Representations of Standard Attribute Syntax's +define UTC Time in Section 2.21 and uses that definition in Section +2.25 on User Certificates. Since UTC Time is being used, there is a +potential millenium issue. + +RFC 1440 on SIFT/UFT: Sender-Initiated/Unsolicited File Transfer +defines an optional DATE command in Section 5 of the form mm/dd/yy +which is subject to millenium issues. + +3.3 "Electronic Mail" + +After reviewing all mail-related RFCs, it was discovered that while +some obsolete standards required two-digit years, all currently used +standards require four-digit years and are thus not prone to typical +Year 2000 problems. + +RFCs 821 and 822, the main basis for SMTP mail exchange and message +format, originally required two-digit years. However, both of these +RFCs were later modified by RFC 1123 in 1989, which strongly +recommended 4-digit years. + +3.4 "Name Serving" + +While not a protocol issue, there is a common habit of writing serial +numbers for DNS zone files in the form YYXXXXXX. The only real +requirement on the serial numbers is that they be increasing (see +RFC 1982 for a complete description) and a change from 99XXXXXX to +00XXXXXX cause a failure. See the section on "Name Serving" for a +complete description of the issues. + +3.5 "Network Management" + +Versions 1 & 2 of SNMP specify the use of UTCTime. This could be an +issue depending on implementations. + +3.6 "Network News" + +There does exist a problem in both NNTP, RFC 977, and the Usenet News +Message Format, RFC 10336. They both specify two-digit year format. +A working group has been formed to update the network news protocols +in general, and addressing this problem is on their list of work +items. + +3.7 "Real-Time Services" + +A Year 2000 problem does occur in the Simple Network Paging Protocol, +versions 2 & 3. Both define a HOLDuntil option which uses a +YYMMDDHHMMSS+/-GMT field. Version 3 also defines a MSTAtus command, +which is required to store,dates and times as YYMMDDHHMMSS+/-GMT. + +There is a small Year 2000 issue in RFC 1786 on the Representation of +IP Routing Policies in the ripe-81++ Routing Registry. In Appendices +C the "changed" object parameter defines a format of +YYMMDD, and similarly in Appendix D "withdrawn" object identifier has +he format of YYMMDD. Since these are only identifiers there should be +little operational impact. Some application software may need to be +modified. + +3.8 "Security" + +RFC 1507 on Distributed Authentication Security Services (DASS) +use UTCTime. Because of the imprecision of the UTC time +definition there could be problems with this protocol. + +RFCs 1421-1424 specifies that PEM uses UTC time formats which could +have a Millenium. + +4. Summary of Other "Periodicity" Problems + +By far, the largest area of "period" problems occurs in the year +2038. Many protocols use a 32-bit field to record the number of +seconds since January 1, 1970. + +4.1 "Name Serivces" + +DNS Security uses 32-bit timestamps which will roll over in 2038. +This issue has been refered to the appropriate Working Group so that +the details of rollover can be established. + +4.2 "Routing" + +IDPR suffers from the classic Year 2038 problem, by having a timestamp +counter which rolls over at that time. + +5. Suggested Solutions + +The real solution to the problem is to use 4 digit year fields for +applications and hardware systems. For counters that key off of a +certain time (January 1, 1970 for example) need to either: define a +wrapping solution, or to define a larger number space (greater than +32-bits), or to make more efficient use of the 32-bit space. A +trivial example might be to use to lower 12 bits to represent the +number of seconds in a day, and use next upper 19 bits to represent +days since January 1, 1970, and the set the highest bit to 1 so that +it is always larger than the current number of seconds since January +1, 1970. This would provide a unique counter until May 28, 3406. +(There are some drawbacks to this example, the most obvious being +the counter is no longer monotonically increasing. It was only +included as a simple example, not a serious suggestion.) + +However, it will be impossible to completely replace currently +deployed systems, so solutions for handling problems are in order. + +5.1 Fixed Solution + +A number of organizations and groups have suggested a fixed solution +to the problem of two digit years. Given a two-digit year YY, if YY +is greater than or equal to 50, the year shall be interpreted as 19YY; +and where YY is less than 50, the year shall be intrepreted as 20YY. + +While a simple and straightforward solution, it only pushes the +problem off 40 to 50 years, until the artificially generated Year +2050 problem needs to be addressed. However, it is easy to implement +and deploy, so it might be the most commonly adopted solution. + +5.2 Sliding Window + +Another solution is the "sliding window" approach. In this approach, +some value N is selected, and any two digit year that is less than or +equal to the current two digit year plus N is considered the future, +while any other two digit year is considered in the past. + +For example, choosing N equal to 10, If the current year is 2012, and +I get a two digit year that is any of 12, 13, 14, 15, 16, 17, 18, 19, +20, 21 or 22, assume it is 20YY (i.e. the future), otherwise consider +it to be in the past(1923-1999, 2000-2011). + +This solution has two advantages. First, no new fixed year problems +are introduced. Second, different applications and protocols could +choose different values of N. The drawback is that this solution is +harder to implement, and to work well the value of N will need to be +constant across different implementations. + +6. Methodology The first task was dividing the types of RFC's into logical groups -rather than the strict numeric publishing order. Fifteen specific +rather than the strict numeric publishing order. Sixteen specific areas were identified. They are: "Autoconfiguration" , "Directory Services", "Disk Sharing", "Games and Chat" ,"Information Services & File Transfer", "Network & Transport Layer", "Electronic Mail", "NTP", Name Serving", "Network Management", "News", "Real Time Services", -"Routing", "Security", and "Virtual Terminal". In addition to these -categories many hundreds of RFC's were immediately eliminated because -of the type of content. That is not to say that all Informational -RFC's were not considered, many did contain some technical content or -overview which demanded scrutiny. +"Routing", "Security", "Virtual Terminal", and "Other". In addition +to these categories, many hundreds of RFC's were immediately eliminated +based on content. That is not to say that all Informational RFC's were +not considered, many did contain some technical content or overview +whichdemanded scrutiny. -Each area was assigned to a team for investigation. Although each team -used whatever additional investigation techniques which seemed +Each area was assigned to a team for investigation. Although each +team used whatever additional investigation techniques which seemed appropriate (including completely reading each RFC, and in some cases the source code for the reference implementation) at minimum each team used an automatic scanning system to search for the following items (case insensitively) in each RFC: - date - GMT - UTCTime - year - yy (that is not part of yyyy) - two-digit, 2-digit, 2digit - century - 1900 & 2000 Note that all of these strings except "UTCTime" may occur in conjunction with a date format that accommodates the Year 2000 -crossing, as well as with one that does not. So "hits" on these string -do not necessarily indicate Year 2000 problems: they simply identify -elements that need to be examined. +crossing, as well as with one that does not. So "hits" on these +string do not necessarily indicate Year 2000 problems: they simply +identify elements that need to be examined. After the documents were scanned, therefore, each "hit" was examined -individually. Those that cause no Year 2000 problems (e.g., those that -encode the year as a two-byte integer, or as a four-character display -string) are not discussed here. Those that do cause Year 2000 problems -are identified in this document, and the nature and impact of the -problems they cause are described. - -Types of Year 2000 Problems - -Summary of Solutions +individually. Those that cause no Year 2000 problems (e.g., those +that encode the year as a two-byte integer, or as a four-character +display string) are not discussed here. Those that do cause Year 2000 +problems are identified in this document, and the nature and impact of +the problems they cause are described. -2.0 Autoconfiguration +7. Autoconfiguration -Summary +7.1 Summary The RFC's which were categorized into this group were primarily the BOOT Protocol (BOOTP) and the Dynamic Host Configuration Protocol (DHCP) for both IP version four and six. Examination of the BOOTP protocols and most popular implementations show no year 2000 problems. All times are references as 32 bit integers in seconds of UTC time. An investigation of all DHCP and the -IPv6 autoconfiguration mechanisms produced no year 2000 problems. All -references to time, in particular lease lengths, are 32 bit integers in -seconds, allowing lease times of well over 100 years. +IPv6 Autoconfiguration mechanisms produced no year 2000 problems. All +references to time, in particular lease lengths, are 32 bit integers +in seconds, allowing lease times of well over 100 years. -Specifics +7.2 Specifics -The following RFCs were examined for possible millenium problems: 906, -951, 1048, 1084, 1395, 1497, 1531, 1532, 1533, 1534, 1541, 1542, 1970, & -1971. RFC 951's only reference to time or dates is a two byte filed in -the packet which is number of second since the hosts was booted. RFC's -1048, 1084, 1395, 1497, 1531, & 1532 have either no references to dates -and time, or they are the same as the RFCs which obsoleted them discuessed -in the next paragraph. +The following RFCs were examined for possible millennium problems: +906, 951, 1048, 1084, 1395, 1497, 1531, 1532, 1533, 1534, 1541, 1542, +1970, & 1971. RFC 951's only reference to time or dates is a two-byte +field in the packet, which is number of second since the hosts, was +booted. RFC's 1048, 1084, 1395, 1497, 1531, & 1532 have either no +references to dates and time, or they are the same as the RFCs, which +obsoleted them, discussed in the next paragraph. -RFC 1533 enumerates all the known DHCP field types and a number of these have -to do with time. Section 3.4 defines a "Time Offset" field which specifies -the offset of the clients subnet in seconds from UTC. This 4 byte field -has no millenium issues. Section 9.2 defines the IP Address Lease Time field -which is used by clients to request a specific lease time. This four byte -field is an unsigned integer containing a number of seconds. Section 9.9 -defines a Renewal Time Value field, Section 9.10 defines a Rebinding Time Value, -both of which are similarly 32 bit fields which have no millenium issues. +RFC 1533 enumerates all the known DHCP field types and a number of +these have to do with time. Section 3.4 defines a "Time Offset" field +which specifies the offset of the clients subnet in seconds from UTC. +This 4 byte field has no millennium issues. Section 9.2 defines the +IP Address Lease Time field which is used by clients to request a +specific lease time. This four byte field is an unsigned integer +containing a number of seconds. Section 9.9 defines a Renewal Time +Value field, Section 9.10 defines a Rebinding Time Value, both of +which are similarly 32 bit fields, which have no millennium issues. RFC 1534 has no references to times or dates. -RFC 1541 has two mentions of times/dates. The first is the "secs" field which, -similarly to RFC 951, is a 16 bit field for the number of seconds since the host -has booted. There is also a discussion in section 3.3 about "Interpretation and -Representation of Time Values" which while clearly states that there is no -millenium or period problems. +RFC 1541 has two mentions of times/dates. The first is the "secs" +field which, similarly to RFC 951, is a 16-bit field for the number of +seconds since the host has booted. There is also a discussion in +section 3.3 about "Interpretation and Representation of Time Values" +which while clearly states that there is no millennium or period +problems. RFC 1542 also references the "secs" field mentioned previously. -"Router Advertisment Message Format" the following fields are defined: Router -Lifetime, Reachable Time, & Retrans Timer. In section 4.6.2 "Prefix Information" -the following are defined: Valid Lifetime, & Prefered Lifetime. In section -6.2.1 "Router Configuration Variables the following are defined: MaxRtrAdvInterval, -MinRtrAdvInterval, AdvReachableTime, AdvRetransTimer, AdvDefaultLifetime, -AdvValidLifetime, & AdvPreferredLifetime. All of these fields specify counters -of some sort which have no millenium or periodicity problems. +RFC 1970 mentions a number of variables, which are time related. In +section 4.2 "Router Advertisement Message Format" the following fields +are defined: Router Lifetime, Reachable Time, & Retrans Timer. In +section 4.6.2 "Prefix Information" the following are defined: Valid +Lifetime, & Preferred Lifetime. In section 6.2.1 "Router +Configuration Variables the following are defined: MaxRtrAdvInterval, +MinRtrAdvInterval, AdvReachableTime, AdvRetransTimer, +AdvDefaultLifetime, AdvValidLifetime, & AdvPreferredLifetime. All of +these fields specify counters of some sort which have no millennium or +periodicity problems. -RFC 1971 has some discussion of preferred lifetimes, depreciated lifetimes and -valide lifetimes of leases, but only discusses them in an expository way. +RFC 1971 has some discussion of preferred lifetimes, depreciated +lifetimes and valid lifetimes of leases, but only discusses them in an +expository way. -3.0 Directory Services +8. Directory Services -Summary +8.1 Summary The RFC's which were categorized into this group were primarily X.500 related RFC's, Whois, Rwhois, Whois++, and the Lightweight Directory Access Protocol (LDAP). Upon review of the Directory Services related RFC's, no serious year 2000 problems were discovered. Some minor issues were noted and -explained below in the specifics portion of this section. +explained below in the specific portion of this section. -Specifics +8.2 Specifics RFCs that mentioned UTC Time or made reference to uTCTimeSyntax could -fail to be Y2K compliant. These should be updated to specify the -four year version of uTCTimeSyntax rather than giving the option of -using a two year date representation. The following RFCs fall into this +fail to be Y2K compliant. These should be updated to specify the four +year version of uTCTimeSyntax rather than giving the option of using a +two-year date representation. The following RFCs fall into this category: rfc1274.txt - References UTC date/time rfc1276.txt - References UTC date/time for version control. rfc1488.txt - References UTC Time as printable strings. rfc1608.txt - Refers to uTCTimeSyntax rfc1609.txt - Refers to uTCTimeSyntax rfc1778.txt - Refers to uTCTimeSyntax Two RFC's have unusual date specifications and specify their own date format. Both of these support Y2K compliant dates. RFC1714 (RWhois) specifies date formats that are not Y2K compliant, -but it also support dates that are. Implementers of the RWhois +but it also supports dates that are. Implementers of the RWhois protocol should only use the %MY4 format -RFC1834 (Whois++) requires the use of dates, but it didn't specify -the format, syntax, or representation of the date string to be used. +RFC1834 (Whois++) requires the use of dates, but it didn't specify the +format, syntax, or representation of the date string to be used. -4.0 Disk Sharing +9. Disk Sharing -Summary +9.1 Summary The RFC's which were categorized into this group were those related to the Network File System (NFS). Other popular disk sharing protocols like SMB and AFS were referred to their respective trustee's for review. After careful review, NFS has no year 2000 problems. -Specifics +9.2 Specifics -The reference to time in this protocol are the times of file data +The references to time in this protocol are the times of file data modification, file access, and file metadata change (mtime, atime, and time, respectively). These times are kept as 32 bit unsigned quantities in seconds since 1970-01-01, and so the NFS protocol will not experience an Epoch event until the year 2106. -5.0 Games and Chat +10. Games and Chat -Summary +10.1 Summary The RFC's which were categorized into this group were related to the -Internet Relay Chat Protocol (IRC). No millenium problems exist in the -IRC protocol. +Internet Relay Chat Protocol (IRC). No millennium problems exist in +the IRC protocol. -Specifics +10.2 Specifics -There is only a single instance of time or date related information in the -IRC protocol as specified by RFC 1459. Section 4.3.4 defines a TIME message -type which queries a server for its local time. No mention is made of the -format of the repy or how it is parsed, the assumption being specific -implementations will handle the reply and parse it appropriately. +There is only a single instance of time or date related information in +the IRC protocol as specified by RFC 1459. Section 4.3.4 defines a +TIME message type which queries a server for its local time. No +mention is made of the format of the reply or how it is parsed, the +assumption being specific implementations will handle the reply and +parse it appropriately. -6.0 Information Services & File Transfer +11. Information Services & File Transfer -Summary +11.1 Summary The RFC's which were categorized into this group were divided among World Wide Web (WWW) protocols and File Transfer Protocols (FTP). WWW protocols include the Hypertext Transfer Protocol (HTTP), a variety of Uniform Resource formats (URL, URAs, etc.) and the HyperText Markup -Language(HTML). FTP protocols include the well known FTP protocol, the -Trivial File Transfer Protocol (TFTP) and a variety of extensions to -these protocols. Other information services includes the Finger +Language(HTML). FTP protocols include the well known FTP protocol, +the Trivial File Transfer Protocol (TFTP) and a variety of extensions +to these protocols. Other information services includes the Finger Protocol and the LPD protocol. -HTTP 1.1 requires all newly generated date stamps to conform to RFC -1123 date formats which are Year 2000 compliant, but it also requires -acceptance of the older non-compliant RFC850 formats. Some specific -recommendations are listed below and have been passed to the HTTP WG. +HTTP 1.1, as defined in RFC 2068, requires all newly generated date +stamps to conform to RFC 1123 date formats which are Year 2000 +compliant, but it also requires acceptance of the older non-compliant +RFC850 formats. Some specific recommendations are listed below and +have been passed to the HTTP WG. -HTML 2.0 could allow a very subtle Year 2000 problem, but once again -this recommendation has been passed on the HTML WG. +HTML 2.0, as defined in RFC 1866, could allow a very subtle Year 2000 +problem, but once again this recommendation has been passed on the +HTML WG. -<> +RFC 1778 on String Representations of Standard Attribute Syntax's +define UTC Time in Section 2.21 and uses that definition in Section +2.25 on User Certificates. Since UTC Time is being used, there is a +potential millenium issue. -Specifics +RFC 1440 on SIFT/UFT: Sender-Initiated/Unsolicited File Transfer +defines an optional DATE command in Section 5 of the form mm/dd/yy +which is subject to millenium issues. -HTTP: +11.2 Specifics -The main IETF standards-track document on the HTTP protocol is -RFC2068 on HTTP 1.1. It notes that historically three different -date formats have been used, and that one of them uses a two-digit -year field. In section 3.3.1 it requires HTTP 1.1 implementations -to generate this RFC1123 format: +The main IETF standards-track document on the HTTP protocol is RFC2068 +on HTTP 1.1. It notes that historically three different date formats +have been used, and that one of them uses a two-digit year field. In +section 3.3.1 it requires HTTP 1.1 implementations to generate this +RFC1123 format: Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 instead of this RFC850 format: Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Unfortunately, many existing servers, serving on the order of one -fifth of the current HTTP traffic, send dates in the ambiguous -RFC850 format. +fifth of the current HTTP traffic, send dates in the ambiguous RFC850 +format. Section 19.3 of the RFC2068 says this: o HTTP/1.1 clients and caches should assume that an RFC-850 date which appears to be more than 50 years in the future is in fact in the past (this helps solve the "year 2000" problem). -This avoids a "stale cache" problem, which would cause the -user to see out-of-date data. - -But to avoid unnecessary delays and bandwidth indicated in Scenario -2 below, this should be extended to say that a date which appears to -be more than 50 years in the past may be assumed to be in the -future, if a future date is legal for that field. +This avoids a "stale cache" problem, which would cause the user to see +out-of-date data. -Scenario 3 indicates that servers may also want to follow these -rules. +RFC 1986 documents experiments with a simple file transfer program +over radio links using Enhanced Trivial FTP (ETFTP). There are a +number of timers defined which are all in seconds and have no year +2000 issues. -Here is some more background and justification for these arguments. +In RFC 1866, on HTML 2.0,the tag allows the embedding of +recommended values for some HTTP headers, including Expires. E.g. -The following headers use full dates: + -HTTP/1.0: - Date: - Expires: # can be in the future - If-Modified-Since: # required to be in the past - Last-Modified: # required to be in the past - Retry-After: # can be in the future, also takes - # relative time - number of seconds +Servers should rewrite these dates into RFC1123 format if necessary. -HTTP/1.1: - If-Range: - If-Unmodified-Since: # required to be in the past +RFC 1807 defines a format for bibliographic records and it specifies a +DATE format, which requires 4 digit year fields. -Note that clock skew between hosts can lead to confusion here - see -the RFC for details. +RFC 1788 defines ICMP Domain Name messages. Section 3 defines a +Domain Name Reply Packet, which contains a signed 32-bit integer. +This timer is not Year 2000 reliant and is certainly large enough for +it purposes. -Here are some scenarios of the implications of RFC850 dates, which -include stale caches, unnecessary requests for things which are -validly cached, delays for the user, extra bandwidth, and presenting -incorrect information to the user. +RFC 1784 on TFTP Timeout Intervals and Transfer Size Options uses a +field for the number of seconds for the timeout. It is an ASCII value +from 1 to 255 octets in length. There is no Y2K issue. -Some cases involve comparisons with the current time, and others may -involve comparisons between dates from different sources. The -abbreviation "/99" is used to imply an RFC850 date with the value -"99" for the year. +RFC 1778 on String Representations of Standard Attribute Syntax's +define UTC Time in Section 2.21 and uses that definition in Section +2.25 on User Certificates. Since UTC Time is being used, there is a +potential millenium issue. -RFC850 date from server +RFC 1777 on LDAP defines a timelimit in Section 4.3 which is expressed +in seconds, but does not define any limits. -Scenario 1: - If a client gets an Expires /99 date after the year 2000, it - should interpret it as 1999, to avoid ending up with a stale - cache entry. +RFC 1440 on SIFT/UFT: Sender-Initiated/Unsolicited File Transfer +defines an optional DATE command in Section 5 of the form mm/dd/yy, +which is subject to millenium issues. - This is as already specified in RFC2068. +RFC 1068 on the Background File Transfer Protocol (BFTP) defines two +commands in Sections B.2.12 and B.2.13, the Submit and Time commands. +>From the example usage's given in Appendix C it is clear that this +protocol will function correctly though the year 9999. -Scenario 2: - If a client gets an Expires /00 date before the year 2000, and - subsequently is faced with a choice to either retrieve the - document from its cache or look for an updated copy, it may - interpret it as the year 2000, to avoid the unnecessary delay - and bandwidth of an extra request. +RFC 1037 on NFILE (a file access protocol) discusses the a Date +representation in Section 7.1 as the number of seconds since January +1, 1900, but does not limit the field size. There should be no Y2K +issues. -RFC850 date from client +RFC 998 on NETBLT defines a Death time in Section 8, which is the +sender's death time in seconds. -Scenario 3: - If a server gets an If-Modified-Since /99 date from a client - after the year 2000, it should interpret it as 1999 when - comparing with the local modification date, in order to - possibly avoid sending a full GET response rather than a - HEAD response. +RFC 978 on the Voice File Interchange Protocol defines the Total Time +of a message to be a 32-bit number of deci-seconds. This limits the +size of a message but has no millenium issues. - Note that an If-Modified-Since header must never be in the - future. +RFC 969 was obsoleted by RFC 998. -HTML +RFC 916 defines the Reliable Asynchronous Transfer Protocol (RATP). +Three timers are discussed in an expository manner in Section 5.4 and +its subsections. There are no relevant issues. -In RFC1866, on HTML 2.0,the tag allows the embedding of -recommended values for some HTTP headers, including Expires. E.g. +RFCs 2122, 2056, 2055, 2054, 2044, 2016, 1960, 1959, 1874, 1865, 1862, +1843, 1842, 1823, 1815, 1808, 1798, 1785, 1783, 1782, 1779, 1766, +1738, 1737, 1736, 1729, 1728, 1727, 1639, 1633, 1630, 1625, 1554, +1545, 1530, 1529, 1528, 1489, 1486, 1436, 1415, 1413, 1350, 1345, +1312, 1302, 1288, 1278, 1241, 1235, 1196, 1194, 1179, 1123, 1003, 971, +965, 959, 949, 913, 887, 866, 865, 864, 863, 862, 797, 795, 783, 775, +765, 751, 743, 742, 740, 737, 725, 722, 707, 691, 683, 662, 640, 624, +614, 607, 599, 412, 411, 410, 407, and 406 were found to have no +references to dates or times, and hence no millenium issues. - +RFCs 712, 697, 633, 630, 622, 610, 593, 592, 589, 573, 571, 570, 553, +551, 549, 543, 535, 532, 525, 520, 514, 506, 505, 504, 501, 499, 493, +490, 487, 486, 485, 480, 479, 478, 477, 472, 468, 467, 463, 454, 451, +448, 446, 438, 437, 436, 430, 429, 418, 414, and 409 were not +available for review. -Servers should rewrite these dates into RFC1123 format if necessary. +RFCS below 400 were considered too obsolete to even consider. -7.0 Network & Transport Layer +12. Network & Transport Layer -Summary +12.1 Summary The RFC's which were categorized into this group were the Internet Protocol (IP) versions four and six, the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), the Point-to-Point Protocol -(PPP) and its extensions, Internet Control Message Protocol (ICMP), the -Address Resolution Protocol (ARP) and Remote Procedure Call (RPC) +(PPP) and its extensions, Internet Control Message Protocol (ICMP), +the Address Resolution Protocol (ARP) and Remote Procedure Call (RPC) protocol. A variety of less known protocols were also examined. -Specifics +After careful review of the nearly 400 RFC's in this catagory, no +millenium or year 2000 problems were found. -<> +12.2 Specifics -8.0 Electronic Mail +discusses the use if mandatory timers, but gives no mention as to how +they are implemented. -Summary +RFC 2114 on a Data Link Switching Client Access Protocol defines a +retry timer of five seconds in Section 3.4.1. + +RFC 2097 on the PPP NetBIOS Frame Control Protocol discuesses several +timer and timeouts in Section 2.1, none of which suffers from a year +2000 problem. + +RFC 2075 on the IP Echo Host Service discusses timestamps and has no +millenium issues. + +RFC 2005 on the Applicability for Mobile IP discusses using timestamps +as a security measure to avoid replay attacks (Section 3.), but does +not quantify them. There are no expected issues. + +RFC 2002 on IP Mobility Support uses a 16-bit field for the lifetime +of a connection and notes the 18.2 hour limitation that this imposes. +Section 5.6.1 on replay protection requires the use of 64-bit time +fields, of a similar format to NTP packets. + +RFC 1981 on Path MTU Discovery for IPv6 discusses timestamps and their +potential use to purge stale information in section 5.3. There is no +millenium issues in this use. + +RFC 1963 on the PPP Serial Data Transport Protocol defines a flow +expiration time in section 4.9 which has no year 2000 issues. + +RFC 1833 on Binding Protocols for ONC RPC Version 2 defines a variable +in Section 2.2.1 called RPCBPROC_GETTIME which returns the local time +in seconds since 1/1/1970. Since this value is not fields width +dependent, it may or may not wrap around the 32-bit value depending on +the operating system parameters. + +RFC 1762 on the PPP DECnet Phase IV Control Protocol discusses a number +of timers in Section 5 (General Considerations). None of these timers +experience any millenium issues. + +RFC 1761 on Snoop Version 2 Packet Capture File Format discusses two +32-bit timestamp values on Section 4 on Packet Record Formats. The +first of these may wrap in the year 2038, but should not effect anything +of any import. + +RFC 1755 on ATM Signalling Support for IP Over ATM discusses timing +issues in Section 3.4 on VC Teardown. These limited timers have no +year 2000 issues. + +RFC 1692 on the Transport Multiplexing Protocol (TMux) defines a TTL in +Section 2.3 and a timer in Section 3.3. Neither of these suffer from +any millenium or year 2000 issues. + +RFC 1661 on PPP defines three timers in Section 4.6, none of which have +any year 2000 issues. + +and the extended timers recommended in it. + +RFC 1575 defines an echo function for CNLP discusses in the narrative +the use of the Lifetime Field in Section 5.3. There is nothing to +suggest that there is any year 2000 issues. + +RFC 1329 on Dual MAC FDDI Networks discusses ARP cache administration +in Section 9.3 and 9.4 and various timers to expire entries. + +RFC 1256 on ICMP Router Discovery Messages talks about lifetime fields +in Section 2 and defines three router configuration variables in Section +4.1. None of these have any millenium issues. + +RFC 792 on ICMP discusses Timestamps and Timestamp Reply messages which +define a 32-bit timestamp which contains the number of milliseconds +since midnight UT. + +RFC 791 on the Internet Protocol defines a packet type 68 which is an +Internet Timestamp, which defines a 32-bit field which contains the +number of milliseconds since midnght UT. + +RFC 781 was defines the same option which is codified in RFC 791 as +a packet type 68. + +RFC's 2126, 2118, 2113, 2107, 2106, 2105, 2098, 2067, 2043, 2023, +2019, 2018, 2009, 2004, 2003, 2001, 1994, 1993, 1990, 1989, 1979, +1978, 1977, 1976, 1975, 1974, 1973, 1972, 1967, 1962, 1954, 1946, +1937, 1936, 1934, 1933, 1932, 1931, 1926, 1924, 1919, 1918, 1917, +1916, 1915, 1897, 1888, 1887, 1885, 1884, 1883, 1881, 1878, 1877, +1868, 1860, 1859, 1853, 1841, 1832, 1831, 1809, 1795, 1791, 1770, +1764, 1763, 1756, 1754, 1752, 1744, 1735, 1726, 1719, 1717, 1710, +1707, 1705, 1698, 1693, 1688, 1687, 1686, 1683, 1682, 1681, 1680, +1679, 1678, 1677, 1676, 1674, 1673, 1672, 1671, 1670, 1669, 1667, +1663, 1662, 1638, 1634, 1631, 1629, 1624, 1622, 1621, 1620, 1619, +1618, 1613, 1605, 1604, 1598, 1590, 1577, 1570, 1561, 1560, 1553, +1552, 1551, 1549, 1548, 1547, 1538, 1526, 1518, 1498, 1490, 1483, +1475, 1466, 1454, 1435, 1434, 1433, 1393, 1390, 1385, 1379, 1378, +1377, 1376, 1375, 1374, 1365, 1363, 1362, 1356, 1347, 1337, 1335, +1334, 1333, 1332, 1331, 1326, 1323, 1314, 1307, 1306, 1294, 1293, +1277, 1263, 1240, 1237, 1236, 1234, 1226, 1223, 1220, 1219, 1210, +1209, 1201, 1191, 1188, 1185, 1172, 1171, 1166, 1162, 1151, 1146, +1145, 1144, 1141, 1139, 1134, 1132, 1122, 1110, 1106, 1103, 1088, +1086, 1085, 1078, 1072, 1071, 1070, 1069, 1063, 1062, 1057, 1055, +1051, 1050, 1046, 1045, 1044, 1042, 1030, 1029, 1027, 1025, 1016, +1008, 1007, 1006, 1002, 1001, 994, 986, 983, 982, 970, 964, 963, 962, +955, 948, 942, 941, 940, 936, 935, 932, 926, 925, 924, 922, 919, 917, +914, 905, 903, 896, 895, 894, 893, 892, 891, 889, 879, 877, 874, 872, +871, 848, 829, 826, 824, 815, 814, 813, 801, 793, 789, 787, 777, 768, +761, 760, 759, 730, 704, 696, 695, 692, 690, 689, 687, 685, 680, 675, +674, 660, 632, 626, 613, 611 were reviewed but were found to have no +millenium references. + +RFC's 594, 591, 576, 550, 548, 528, 521, 489, 488, 473, 460, 459, 450, +449, 445, 442, 434, 426, 417, 398, 395, 394, 359, 357, 348, 347, 346, +343, 312, 301, 300, 271, 241, 210, 203, 202, 197, 190, 178, 176, 175, +166, 165, 161, 151, 150, 146, 145, 143, 142, 128, 127, 123, 122, 93, +91, 80, 79, 70, 67, 65, 62, 60, 59, 56, 55, 54, 53, 41, 38, 33, 23, +22, 20, 19, 17, 12 were deemed too old to be considered for millenium +investigation. + +13. Electronic Mail + +13.1 Summary The RFC's which were categorized into this group were the Simple Mail Transfer Protocol (SMTP), Internet Mail Access Protocol (IMAP), Post Office Protocol (POP), Multipurpose Internet Mail Exchange (MIME), and X.400 to SMTP interaction. After reviewing all mail-related RFCs, it was discovered that while -some obsolete standards required two-digit years, all currently-used +some obsolete standards required two-digit years, all currently used standards require four-digit years and are thus not prone to typical Year 2000 problems. -Specifics +13.2 Specifics RFCs 821 and 822, the main basis for SMTP mail exchange and message format, originally required two-digit years. However, both of these RFCs were later modified by RFC 1123 in 1989, which strongly recommended 4-digit years. Although there might be a few very old SMTP systems using two-digit years, it is believed that almost all mail sent over the Internet today uses four-digit years. Mail that contains two-digit years in its SMTP headers will not "fail", but -might be missorted in message stores and mail user agents. This +might be mis-sorted in message stores and mail user agents. This problem is avoided entirely by taking the RFC 1123 change as a requirement, rather than merely as a recommendation. IMAP versions 1, 2, and 3 used two-digit years, but IMAP version 4 (defined in RFCs 1730 and 1732 in 1994) requires four-digit -years. There are still a few IMAP 2 servers and clients in use on -the Internet today, but IMAP version 4 has already take over almost -all of the IMAP market. Mail stored on an IMAP server or client with -two-digit years will not "fail", but could possibly be missorted or +years. There are still a few IMAP 2 servers and clients in use on the +Internet today, but IMAP version 4 has already take over almost all of +the IMAP market. Mail stored on an IMAP server or client with +two-digit years will not "fail", but could possibly be mis-sorted or prematurely expired. RFC 1153 describes a format for digests of mailing lists, and uses -two-digit dates. This format is not widely used. The use of -two-digit dates could possibly cause missorting of stored messages. +two-digit dates. This format is not widely used. The use of two-digit +dates could possibly cause missorting of stored messages. RFC 1327, which describes mapping between X.400 mail and SMTP mail, uses the UTCTime format. -RFC 1422 describes the structure of certificates that were used in -PEM (and are expected to be used in many other mail and non-mail -services). Those certificates use dates in UTCTime -format. Poorly-written software might prematurely expire or validate -a certificate based on comparisons of the date with the current -date, although no current software is known to do this. +RFC 1422 describes the structure of certificates that were used in PEM +(and are expected to be used in many other mail and non-mail +services). Those certificates use dates in UTCTime format. Poorly +written software might prematurely expire or validate a certificate +based on comparisons of the date with the current date, although no +current software is known to do this. -9.0 Network Time Protocols +14. Network Time Protocols -Summary +14.1 Summary The RFC's which were categorized into this group were the Network Time Protocol (NTP), and the Time Protocol. NTP has been certified year 2000 compliant, while the Time Protocol will "roll over" at Thu Feb 07 00:54:54 2036 GMT. Since NTP is the current defacto standard for network time this does not seem to be an issue. -Specifics +14.2 Specifics There is no reference anywhere in the NTP specification or implementation to any reference epoch other than 1 January 1900. In short, NTP doesn't know anything about the millennium. -From the Time Protocol RFC (868): +>From the Time Protocol RFC (868): S: Send the time as a 32 bit binary number. ... The time is the number of seconds since 00:00 (midnight) 1 January 1900 GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this base will serve until the year 2036. -10.0 Name Services +15. Name Services -Summary +15.1 Summary The RFC's which were categorized into this group were the Domain Name -System (DNS), it's advanced add on features (Incremental Zone Transfer, -etc.). +System (DNS), it's advanced add on features (Incremental Zone +Transfer, etc.). -Specifics +There have been no year 2000 relayed problems found with the DNS +protocols, or common implementations of them. -<> +15.2 Specifics -11.0 Network Management +One is a common practice of writing serial numbers in zone files as if +they represent a date, and using only two digits of the year. That +practice cannot survive into the year 2000. This is not a protocol +problem, the serial number is simply an integer, and any value is OK, +provided it always increases (see rfc1982 for a definition of what +that means). In any case, a change from 97abcd (or similar) to 00abcd +would be a decrease and so is not permitted. Zone file maintainers +have two choices, one easy (though irrational) one would be to +continue from 99 to 100 and so on. The other, is simply to switch, at +any time between now and when the serial number first needs updating +after the year 2000, to use 4 digits to represent the year instead of +2. As long as there are no more than 6 digits in the "abcd" part, and +this is done sometime before the year 2100, this is always an +increase, and therefore always safe. Should any zone files be of the +form yyabcdefg (with 7 digits after a 2-digit year) then the +procedures of section 7 of rfc2182 should be adopted to convert the +serial number to some other value. -Summary +The other item of note is related to timestamps in DNS security. +Those are represented as 32 bit counts of seconds, based in 1970, and +hence have no year 2000 problems. however, they do obviously have a +natural end of life, and sometime before that time is reached, the +definitions of those fields need to be corrected, perhaps to allow +them to represent the number of seconds elapsed since the base, modulo +2^32, which is likely to be adequate for the purposes of DNS security +(signatures and keys are unlikely to need to be valid for more than 70 +years). In any case, more work is needed in this area in the not too +far distant future. + +16 Network Management + +16.1 Summary The RFC's which were categorized into this group were the Simple Network Management Protocol (SNMP), a large number of Management -Information Bases (MIBs) and the Common Management Information Protocol -(CMIP). +Information Bases (MIBs) and the Common Management Information +Protocol (CMIP). Although a few discrepancies have been found and outlined below, none -of them should have an impacts on interoperability. +of them should have an impact on interoperability. -Specifics +16.2 Specifics -1. Use of GeneralizedTime in CMOT (RFCs 1095 and 1189) +16.2.1 Use of GeneralizedTime in CMOT as defined in RFCs 1095 and 1189. The standards for CMIP over TCP/IP specify an unusual use for the -GeneralizedTime type. (GeneralizedTime has a four-digit representation -of the year.) +GeneralizedTime type. (GeneralizedTime has a four-digit +representation of the year.) If the system generating the PDU does not have the current time, yet -does have the time since last boot, then GeneralizedTime can be used to -encode this information. The time since last boot will be added to the -base time "0001 Jan 1 00:00:00.00" using the Gregorian calendar +does have the time since last boot, then GeneralizedTime can be used +to encode this information. The time since last boot will be added to +the base time "0001 Jan 1 00:00:00.00" using the Gregorian calendar algorithm. This is really a "Year 0" problem rather than a Year 2000 problem, and in any case, CMOT is not currently deployed. -2. UTCTime in SNMP Definitions +16.2.2 UTCTime in SNMP Definitions UTCTime is an ASN.1 type that includes a two-digit representation of -the year. There are several options for UTCTime in ASN.1, that vary in -precision and in local versus GMT, but these options all have two-digit -years. The standards for SNMP definitions specify one particular -format: +the year. There are several options for UTCTime in ASN.1, that vary +in precision and in local versus GMT, but these options all have +two-digit years. The standards for SNMP definitions specify one +particular format: YYMMDDHHMMZ The first usage of UTCTime in the standards for SNMP definitions goes all the way back to RFC 1303. It has persisted unchanged up through the current specifications in RFC 1902. The role of UTCTime in SNMP definitions is to record the history of an SNMP MIB module in the module itself, via two ASN.1 macros: o LAST-UPDATED o REVISION Applications that store and use MIB modules need to be smart about interpreting these UTCTimes, but with one exception, the times do not actually flow in the network. This one exception is the -appnNodeMibVersion object in the APPN MIB (currently draft-ietf-snanau- -appnmib-04.txt, but soon to be published as an RFC), which returns the -value of LAST-UPDATED from the version of the APPN MIB that an agent -has implemented. An application that can correctly interpret UTCTimes, -by prepending a "19" or a "20" as appropriate, in the MIB modules it -has stored locally will be able to interpret the value of this object -correctly as well. +appnNodeMibVersion object in the APPN MIB (currently +draft-ietf-snanau- appnmib-04.txt, but soon to be published as an +RFC), which returns the value of LAST-UPDATED from the version of the +APPN MIB that an agent has implemented. An application that can +correctly interpret UTCTimes, by prepending a "19" or a "20" as +appropriate, in the MIB modules it has stored locally will be able to +interpret the value of this object correctly as well. -3. Objects in the Printer MIB (RFC 1559) +16.2.3 Objects in the Printer MIB (RFC 1559) -There are two objects in the Printer MIB that allow use of a date as an -object value with no explicit guidance for formatting the value. The -objects are prtInterpreterLangVersion and prtInterpreterVersion. Both -are defined with a syntax of OCTET STRING. The descriptions for the -objects allow the object value to contain a date, version code or other -product specific information to identify the interpreter or language. -The descriptions do not include an explicit statement recommending use -of a four-digit year when a date is used as the object value. +There are two objects in the Printer MIB that allow use of a date as +an object value with no explicit guidance for formatting the value. +The objects are prtInterpreterLangVersion and prtInterpreterVersion. +Both are defined with a syntax of OCTET STRING. The descriptions for +the objects allow the object value to contain a date, version code or +other product specific information to identify the interpreter or +language. The descriptions do not include an explicit statement +recommending use of a four-digit year when a date is used as the +object value. -4. Dates in Mobile Network Tracing Records (RFC 2041) +16.2.4 Dates in Mobile Network Tracing Records (RFC 2041) The RFC specifies trace headers and footers with date fields that are character arrays of size 32. While 32 characters certainly provide enough room for a four-digit year, there's no explicit statement that these years must be represented with four digits. -12.0 Network News +17 Network News -Summary +17.1 Summary The RFC's which were categorized into this group were related to the Network News Protocol (NNTP). -There does exist a problem in both NNTP and the Usenet News Message -Format. They both specify two digit year format. A working group has -been formed to update the network news protocols in general, and -addressing this problem is on their list of work items. +There does exist a problem in both NNTP, RFC 977, and the Usenet News +Message Format, RFC 10336. They both specify two-digit year format. +A working group has been formed to update the network news protocols +in general, and addressing this problem is on their list of work +items. -Specifics +17.2 Specifics -<> +The NNTP transfer protocols defined in RFC 977. Sections 3.7.1, the +definition of the NEWGROUPS command, and 3.8.1, the NEWNEWS command, +that dates must be specified in YYMMDD format. -13.0 Real Time Services +The format for USENET news messages is defined in RFC 1036. The Date +line is defined in section 2.1.2 and it is specified in RFC-822 +format. It specifically disallows the standard UNIX ctime(3) format, +which would allow for four digit years. Section 2.2.4 on Expires also +mandates the same two-digit year format. -Summary +18. Real Time Services + +18.1 Summary The RFC's which were categorized into this group were related to IP -Multicast, RTP, and Internet Stream Protocol. +Multicast, RTP, and Internet Stream Protocol. A Year 2000 problem +does occur in the Simple Network Paging Protocol, versions 2 & 3. +Both define a HOLDuntil option which uses a YYMMDDHHMMSS+/-GMT field. +Version 3 also defines a MSTAtus command, which is required to store, +dates and times as YYMMDDHHMMSS+/-GMT. -<> +18.2 Specifics -Specifics +RFC 2102 discusses Multicast support for NIMROD and has no mention of +dates or time. RFC 2090 on TFTP Multicast options is also free from +any date/time references. -14.0 Routing +RFC 2038 on RTP MPEG formats has three references to time: a +Presentation Time Stamp (PTS), a Decoding Time Stamp (DTS), and a +System Clock (SC) reference time. Each RTP packet contains a +timestamp derived from the sender 90 kHz clock reference. Each of the +header fields are defined in section 2.1, 3, and 3.3 are 32 bit +fields. No mention is made of a "zero" start time, so it is presumed +that this format will be valid until at least 2038. -Summary +Similarly RFC 2035 on the RTP JPEG format defines the same timestamp +in section 3. RFC 2032 on RTP H.261 video streams uses a calculated +time based on the original frame so once again there is no millenium +issue. RFC 2029 on the RTP format for Sun's CellB video encoding +mentions the RTP timestamp in section 2.1. + +RFC 2022 defines support for multicast over UNI 3.0/3.1 based ATM +networks. Section 5. defines a timeout value for connections between +one and twenty minutes. Section 5.1.1 discusses several timers that +are bound between five and ten seconds, while 5.1.3 requires an +inactivity timer, which should also run between one and twenty +minutes. Sections 5.1.5, 5.1.5.1, 5.1.5.2, 5.2.2, 5.4, 5.4.1, 5.4.2, +5.4.3, 6.1.3 and Appendix E all defines numerous timers, none of which +have any millenium issues. + +RFC 1890 on RTP profiles for audio and video conferences discusses a +sampling frequency which has no issues. RFC 1889 on RTP discusses +time formats in section 4, as the same 64 bit unsigned integer format +that NTP uses. There is a "period" problem, which will occur in the +year 2106. Section 5.1 is a more formalized discussion of the +timestamp properties, while Section 6.3.1 discusses a variety of +different timers all using the 64 bit field format, or a compressed +32-bit version of the inner octet of bytes. Section 8.2 discusses +loop detection and how the various timers are used to determine if +looping occurs. + +RFC 1861 on Version 3 of the Simple Network Paging Protocol does have +a Year 2000 problem. The protocol defines a HOLDuntil command in +section 4.5.6 and a MSTAtus command in section 4.6.10, both of which +require dates/times to be stored as YYMMDDHHMMSS+/-GMT. Clearly this +format will be invalid after the end of 1999. + +RFC 1821 has no date/time references. RFC 1819 on Version 2 of the +Internet Stream Protocol defines a HELLO message format in section +6.1.2, which does contain a timer which is updated every millisecond. +No year 2000 problems exist with this protocol. + +RFC 1645 on Version 2 of the Simple Network Paging Protocol contains +the same HOLDuntil field problem as version 3. The definition is +contained section 4.4.6. + +RFC 1458 on the Requirements of Multicast Protocols discusses a +retransmission timer in section 4.23. and a general discussion of +timer expiration in section 5, neither of which have any millenium +concerns. RFC 1301 on the Multicast Transport Protocol defines a +heartbeat interval of time in section 2.1, as well as retention and +windows. Formal definitions for each are contained in sections 2.2.7, +2.2.8 and 2.2.9. The heartbeat is a 32 bit unsigned field, while the +Window and Retention are both 16 bit unsigned fields. Section 3.4.2 +gives examples values for these fields, which indicate no millenium +issues. + +RFC 1193 on Client Requirements for Real Time Services talks about +time in section 4.4, but there are no Year 2000 issues. RFC 1190 have +been obsoleted by RFC 1819, but the hello timer issues are similar. + +RFCs 1789, 1768, 1703, 1614, 1569, 1568, 1546, 1469, 1453, 1313, 1257, +1197, 1112, 1054, 988, 966, 947, 809, 804, 803, 798, 769, 741, 511, +508, 420, 408 and 251 contain no date or time references. + +19. Routing + +19.1 Summary The RFC's which were categorized into this group were Routing Information Protocol (RIP), the Open Shortest Path First (OSPF) protocol, Classless InterDomain Routing (CIDR),the Border Gateway Protocol (BGP), and the InterDomain Routing Protocol (IDRP). After careful examination both BGP and RIP have been found Year 2000 compliant. -<> - -Specifics - -BGP4 +There is a small Year 2000 issue in RFC 1786 on the Representation of +IP Routing Policies in the ripe-81++ Routing Registry. In Appendices +C the "changed" object parameter defines a format of +YYMMDD, and similarly in Appendix D "withdrawn" object identifier has +he format of YYMMDD. Since these are only identifiers there should be +little operational impact. Some application software may need to be +modified. -The BGP4 protocol or the BGP4 FSM do not have knowledge of absolute -time. There is a notion of relative time inside BGP4, and this is -visible in the fact that BGP4 has five timers. +IDPR suffers from the classic Year 2038 problem, by having a timestamp +counter which rolls over at that time. -The five timers are not a problem, since they keep relative time, as -stated above. Below excerpts for proof from the RFC can be found: +19.2 Specifics -* Hold timer: +RFC 2091 on Extensions to RIP to Support Demand Circuits defines three +required and one optional timers in section 6. The Database Timer +(6.1), the Hold down Timer (6.2), the Retransmission Time (6.3) and +the Over-Subscription Timer (6.4) are all counters, which have no +millenium, issues. RFC 2081 on the applicability of RIPng discusses +deletion of routes for a variety of issues, one of which is the +garbage- collection timer exceeds 120 seconds. There are no Year 2000 +issues. RFC 2080 on RIPng for IPv6, discusses various times in +section 2.6, none of which have any millenium problems. -The calculated value indicates the maximum number of seconds that -may elapse between the receipt of successive KEEPALIVE, and/or -UPDATE messages by the sender. -[...] +RFC 1987 on Ipsilon's General Switch Management protocol there is a +Duration field defined in section 4, which has no relevant problems. +Section 8.2 defines the procedure for dealing with timers. RFC 1953 +on Ipsilon's Flow Management Specification for IPv4 defines the same +procedure in section 3.2, as well as a lifetime field in the Redirect +Message (Section 4.1). There are no millenium issues in either case. -The suggested value for the Hold Time is 90 seconds. +There is a small Year 2000 issue in RFC 1786 on the Representation of +IP Routing Policies in the ripe-81++ Routing Registry. In Appendices +C the "changed" object parameter defines a format of +YYMMDD, and similarly in Appendix D "withdrawn" object identifier has +he format of YYMMDD. Since these are only identifiers there should be +little operational impact. Some application software may need to be +modified. -* ConnectRetry timer: +RFC 1771 defines the Border Gateway Protocol (BGP). BGP does not have +knowledge of absolute time, only relative time. There are five timers +defined: Hold Timer, ConnectRetry Timer, KeepAlive Timer, +MinRoueAdvertisementInterval and MinASOriginationInterval. There are +no known issues regarding BGP and the millenium. -The value of the initial timer shall be 60 seconds. The time shall -be doubled for each consecutive retry. -[...] +In RFC 1584, which defines Multicast Extensions to OSPF, three timers +are defined in section 8.2: IGMPPollingInterval, IGMPTimeout, and IGMP +polling timer. Section 8.4 defines an age parameter for the local +groups database and section 9.3 outlines how to implement that age +parameter. It is not expected that any connections lifetime will be +long enough to cause any issues with these timers. -The suggested value for the ConnectRetry timer is 120 seconds. +RFC 1583, OSPF, there are two types of timers defined in section 4.4, +single-shot timers and interval timers. There are a number of timers +defined in Section 9 including: HelloInterval, RouterDeadInterval, +InfTransDelay, Hello Timer, Wait Timer and RxmtInterval. Section 10 +also defines the Inactivity Timer. No millenium problem exists for +any of these timers. -* KeepAlive timer: +RFC 1582 is an earlier version of RFC 2091. Section 7 documents the +same timers as noted above, with the same lack of a millenium issue. -KeepAlive messages are sent periodically to ensure the liveness of -the connection. -[...] +RFC 1504 on Appletalk Update-Based Routing Protocol defines a +10-second period in Section 3, and hence has no relevant issues. -The suggested value for the KeepAlive timer is 30 seconds. +RFC 1479 which specifies IDPR Version 1, defines a timestamp field in +section 1.5.1, which is a 32 bit unsigned integer number of seconds +since January 1, 1970. The authors recognize the problem of timestamp +exhaustion in 2038, but feel that the protocol will not be in use for +that period. Sections 1.7, 2.1, and 4.3.1 also discuss the timestamp +field. RFC 1478 on the IDPR Architecture, also discusses the same +timestamp field in section 3.3.4. RFC 1477 again refers to the IDPR +timestamp in section 4.2. Thus IDPR has no Year 2000 issue, but does +have a period problem in the year 2038. -* MinRouteAdvertisementInterval: +RFC 1075 on Distance Vector Multicast Routing Protocol devotes section +7 to time values. None of the timers have any millenium issues. RFC +1074, on the NFSNET backbone SPF IGP defines several hardcoded timers +values in section 5. -The parameter MinRouteAdvertisementInterval determines the minimum -amount of time that must elapse between advertisement of routes to a -particular destination from a single BGP speaker. -[...] +RFC 1058 on RIP discusses the 30-second timers in section 3.3. There is no millenium +issues related to RIP. -The suggested value for the MinRouteAdvertisementInterval is 30 -seconds. +RFC 995 on the Requirements for Internet Gateways has extensive +discussions of timers in section 7.1 and throughout A.1 and A.2. None +of these timers suffer from the millenium problem. -* MinASOriginationInterval: +RFC 911 on EGP on Berkeley Unix recommend timer values of 30 and 120 seconds. -The parameter MinASOriginationInterval determines the minimum amount -of time that must elapse between successive advertisements of UPDATE -messages that report changes within the advertising BGP speaker's -own autonomous systems. -[...] +RFC 904 which defines the Exterior Gateway Protocol (EGP). There are +a number of timers discussed in sections 4.1.1 and 4.1.4. None of +these timers suffer from any relevant problems. -The suggested value for the MinASOriginationInterval is 15 seconds. +RFCs 2103, 2092, 2073, 2072, 2042, 2008, 1998, 1997, 1992, 1966, 1955, +1940, 1930, 1925, 1923, 1863, 1817, 1812, 1793, 1787, 1774, 1773, +1772, 1765, 1753, 1745, 1723, 1722, 1721, 1716, 1702, 1701, 1668, +1656, 1655, 1654, 1587, 1586, 1585, 1581, 1520, 1519, 1517, 1482, +1476, 1439, 1403, 1397, 1388, 1387, 1383, 1380, 1371, 1370, 1364, +1338, 1322, 1268, 1267, 1266, 1265, 1264, 1254, 1246, 1245, 1222, +1195, 1164, 1163, 1142, 1136, 1133, 1126, 1125, 1124,1104, 1102, 1092, +1009, 985, 981, 975, 950, 898, 890, 888, 875, and 823 contain no date +or time references. -15.0 Security +20. Security -Summary +20.1 Summary The RFC's which were categorized into this group were kerberos authentication protocol, Remote Authentication Dial In User Service (RADIUS), One Time Password System (OTP), Privacy Enhanced Mail (PEM), security extensions to a variety of protocols including (but not -limited to) RIPv2, HTTP, MIME, PPP, IP, Telnet and FTP. Encryption and -authentication algorithms are also examined. +limited to) RIPv2, HTTP, MIME, PPP, IP, Telnet and FTP. Encryption +and authentication algorithms are also examined. -<> +RFC 1507 on Distributed Authentication Security Services (DASS) +discusses time and secure time in an expository manner in Sections +1.2.2, 1.4.4 and 2.1. Section 3.6 defines absolute time as an UTC +time with a precision of 1 second, and Section 4.1 discusses ANS.1 +encoding of time values. Because of the imprecision of the UTC time +definition there could be problems with this protocol. -Specifics +RFCs 1421-1424 specifies that PEM uses UTC time formats which could +have a Millenium issue since the year specification only provides the +last two digits of the year. -16.0 Virtual Terminal +20,2 Specifics -Summary +RFC 2082 on RIP-2 MD% Authentication requires storage of security keys +for a specified lifetime in sections 4.1 and 4.2. There are no +millenium issues in this protocol. + +RFC 2078 on the GSSAPI Version 2 defines numerous calls that use +timers for inputs and outputs. Sections 2.1.1, 2.1.3, 2.1.4, 2.1.5, +2.2.1, 2.2.2, 2.2.5 and 2.2.6 all use the lifetime_rec field, which is +defined as an integer counter in seconds. There should be no relevant +problems with this protocol. + +RFC 2069 on Digest Authentication for HTTP, defines a 'date' and a +'last-modified' field in Section 2.1.2. Both are required to be RFC +1123 formats which is not subject to millenium issues. Section 3.2 +discusses dates and times in the context of thwarting replay attacks, +but have no relevant issues. + +RFC 2065 on DNS Security extensions first discusses time in section +2.3.3. The SIG RDATA format is defined in Section 4.1 discusses "time +signed" field and defines it to be a 32 bit unsigned integer number of +seconds since January 1, 1970. There will be a period problem in 2038 +because of rollover. Section 4.5 on the file representations of SIG +RRs specifies the time field is expressed as YYYYMMDDHHMMSS which is +clearly Year 2000 compliant. + +RFC 2059 on RADIUS account formats defines a "time" attribute, which +is optional which is a 32 bit unsigned integer number of seconds since +January 1, 1970. Likewise RFC 2058 on RADIUS also defines this +optional attribute in the same way. There will be a potential period +problem that occurs on 2038. + +RFC 2035 on the Simple Public Key GSSAPI Mechanism talks about secure +timestamps in the background and overview sections only in an +expository manner. + +RFC 1969 on the PPP DES Encryption Protocol uses time as an example in +Section 4 when discussing how to encrypt the first packet of a stream. +It is suggested that the first 32 bits be used for the number of +seconds since January 1, 1970. There could thus be a potential +operations problem in 2038. + +RFC 1898 on the CyberCash Credit Card Protocol provides an example +message in Section 2.7 which uses a date field of the form +YYYYMMDDHHMM that is clearly Y2K compliant. + +RFC 1510, which defines Kerberos Version 5, makes extensive use of +times in the security model. There are discussions in the +Introduction, as well as Sections 1.2, and 3.1.3. Kerberos uses ASN.1 +definitions to abstract values, and hence defines a base definition +for KerberosTime which is a generalized time format in Section 5.2. +>From the text: "Example: The only valid format for UTC time 6 minutes, +27 seconds after 9 p.m. on 6 November 1985 is 19851106210627Z." A +side note is that the MIT reference implementation of the Kerberos, by +default set the expiration of tickets to December 31, 1999. This is +not protocol related but could have some operational impacts. + +RFC 1509 on GSSAPI C-bindings makes a single reference that all +counters are in seconds and assigned as 32 bit unsigned integers. +Hence GSSAPI mechanisms may have problems in 2038. + +RFC 1507 on Distributed Authentication Security Services (DASS) +discusses time and secure time in an expository manner in Sections +1.2.2, 1.4.4 and 2.1. Section 3.6 defines absolute time as an UTC +time with a precision of 1 second, and Section 4.1 discusses ANS.1 +encoding of time values. Because of the imprecision of the UTC time +definition there could be problems with this protocol. + +RFC 1424 on PEM Part IV defines a self-signed certificate request in +Section 3.1. The validity period start and end times are both +suggested to be January 1, 1970. RFC 1422 on PEM Part II defines the +validity period for a certificate in Section 3.3.6. It is recommended +that UTC Time formats are used, and notes the lack of a century so +that comparisons between different centuries must be done with care. +No suggestions on how to do this are included. Sections 3.5.2 also +discusses validity period in PEM CRLs. RFC 1421 on PEM Part I +discusses validity periods in an expository way. PEM as a whole could +have problems after December 31, 1999 based on its use of UTC Time. + +RFCs 1113, 1114, and 1115 specify the original version of PEM and have +been obsoleted bye 1421, 1422, 1423, & 1424. + +RFCs 2104, 2085, 2084, 2057, 2040, 2015, 1984, 1968, 1964, 1961, 1949, +1948, 1938, 1929, 1928, 1858, 1852, 1851, 1829, 1828, 1827, 1826, +1825, 1824, 1760, 1751, 1750, 1704, 1675, 1579, 1535, 1511, 1492, +1457, 1455, 1423, 1416, 1412, 1411, 1409, 1408, 1321, 1320, 1319, +1281, 1244, 1186, 1170, 1156, 1108, 1004, 972, 931, 927, 912, and 644 +contain no date or time references. + +21. Virtual Terminal + +21.1 Summary The RFC's which were categorized into this group were Telnet and its many extensions, as well as the Secure SHell (SSH) protocol. The X -window systems was not considered since it is not an IETF protocol. +window system was not considered since it is not an IETF protocol. Official acknowledgement by the trustee's of the X window system was -given that the protocol will be examined by them. +given that they will examine the protocol. Unencrypted Telnet and TN3270 have both been found to be Year 2000 Compliant. The SSH protocols are also Year 2000 compliant. -Specifics +21.2 Specifics -17.0 Security Considerations +RFC 1013 on the X Windows version 11 alpha protocol defines are 32 bit +unsigned integer timestamp in Section 4. + +RFCs 2066, 1647, 1576, 1572, 1571, 1372, 1282, 1258, 1221, 1205, 1184, +1143, 1116, 1097, 1096, 1091, 1080, 1079, 1073, 1053, 1043, 1041, +1005, 946, 933, 930, 929, 907, 885, 884, 878, 861, 860, 859, 858, 857, +856, 855, 854, 851, 818, 802, 782, 779, 764, 749, 748, 747, 746, 736, +735, 734, 732, 731, 729, 728, 727, 726, 721, 719, 718, 701, 698, 658, +657, 656, 655, 654, 653, 652, 651, 647, 636, 431, 399, 393, 386, 365, +352, 340, 339, 328, 311, 297, 231, and 215 contain no date or time +references. + +RFCs 703, 702, 688, 679, 669, 659, 600, 596, 595, 587, 563, 562, 560, +559, 513, 495, 470, 466, 461, 447, 435, 377, 364, 318, 296, 216, 206, +205, 177, 158, 139, 137, 110, 97 were unavailable. + +22. Other + +22.1 Summary + +This grouping was a hodge-podge of informational RFCs, April Fool's +Jokes, IANA lists, and experimental RFCs. None were found to have any +millenium issues. + +22.2 Specifics + +RFCs 2123, 2036, 2014, 2000, 1999, 1958, 1935, 1900, 1879, 1855, 1822, +1814, 1810, 1799, 1776, 1718, 1715, 1700, 1699, 1640, 1627, 1610, +1607, 1601, 1600, 1599, 1594, 1580, 1578, 1574, 1550, 1540, 1539, +1527, 1499, 1463, 1462, 1438, 1410, 1402, 1401, 1391, 1367, 1366, +1360, 1359, 1358, 1349, 1340, 1336, 1325, 1324, 1300, 1291, 1287, +1261, 1250, 1249, 1206, 1200, 1199, 1177, 1175, 1174, 1152, 1149, +1140, 1135, 1127, 1118, 1111, 1100, 1099, 1077, 1060, 1039, 1020, +1019, 999, 997, 992, 990, 980, 960, 945, 944, 943, 939, 909, 902, 900, +899, 873, 869, 846, 845, 844, 843, 842, 840, 839, 838, 837, 836, 835, +834, 833, 832, 831, 820, 817, 800, 776, 774, 770, 766, 762, 758, 755, +750, 745, 717, 637, 603, 602, 590, 581, 578, 529, 527, 526, 523, 519, +518, 496, 491, 432, 404, 403, 401, 372, 363, 356, 345, 330, 329, 327, +317, 316, 313, 295, 282, 263, 242, 239, 234, 232, 225, 223, 213, 209, +204, 198, 195, 173, 170, 169, 167, 154, 149, 148, 147, 140, 138, 132, +131, 130, 129, 126, 121, 112, 109, 107, 100, 95, 90, 68, 64, 57, 52, +51, 46, 43, 37, 27, 25, 21, 15, 10, and 9 were examined and none were +found to have any date or time references, let alone millenium or Year +2000 issues. + +23. Security Considerations Although this document does consider the implications of various security protocols, there is no need for additional security considerations. The effect of a potential year 2000 problem may cause some security problems, but those problems are more of specific applications rather than protocol deficiencies introduced in this document. -18.0 References +24. References Because of the exhaustive nature of this investigation, the reader is -referred to the list of published RFC's evailable from the IETF +referred to the list of published RFC's available from the IETF Secretariat or the RFC Editor, rather than republishing them here. -19.0 Editors Address +25. Editors Address Philip J. Nesser II Nesser & Nesser Consulting 13501 100th Ave N.E. Suite 5202 Kirkland, WA 98052 (425)481-4303 (voice) (425)482-9721 (fax) pjnesser@nesser.com pjnesser@martigny.ai.mit.edu -20.0 Appendices +Appendix A: List of RFC's for each Area -There were several appendices in the first draft of this document, but -they have not changed, and it was decided to leave them out of the -final version. If the reader wished to see any of the following -information they should obtain the -00 version of this draft: +The following list contains the RFC's grouped by area that were +searched for year 2000 problems. + +Each line contains three fields are separated by '::'. The first +filed is the RFC number, the second field is the type of RFC (S = +Standard, DS = Draft Standard, PS = Proposed Standard, E = +Experimental, H = Historical, I = Informational, BC = Best Current +Practice, '' = No Type), and the third field is the Title. + +A.1 Autoconfiguration + +1971:: PS:: IPv6 Stateless Address Autoconfiguration +1970:: PS:: Neighbor Discovery for IP Version 6 (IPv6) +1542:: PS:: Clarifications and Extensions for the Bootstrap Protocol +1541:: PS:: Dynamic Host Configuration Protocol +1534:: PS:: Interoperation Between DHCP and BOOTP +1533:: PS:: DHCP Options and BOOTP Vendor Extensions +1532:: PS:: Clarifications and Extensions for the Bootstrap Protocol +1531:: PS:: Dynamic Host Configuration Protocol +1497:: DS:: BOOTP Vendor Information Extensions +1395:: DS:: BOOTP Vendor Information Extensions +1084:: DS:: BOOTP vendor information extensions +1048:: DS:: BOOTP vendor information extensions +951:: DS:: Bootstrap Protocol +906:: :: Bootstrap loading using TFTP + +A.2 Directory Services + +2120:: E :: Managing the X.500 Root Naming Context +2079:: PS:: Definition of X.500 Attribute Types and an Object Class + to Hold Uniform Resource Identifiers (URIs) +1943:: I:: Building an X.500 Directory Service in the US +1914:: PS:: How to interact with a Whois++ mesh +1913:: PS:: Architecture of the Whois++ Index Service +1838:: E:: Use of the X.500 Directory to support mapping between + X.400 and RFC 822 Addresses +1837:: E:: Representing Tables and Subtrees in the X.500 Directory +1836:: E:: Representing the O/R Address hierarchy in the X.500 + Directory Information Tree +1835:: PS:: Architecture of the WHOIS++ service +1834:: I:: Whois and Network Information Lookup Service Whois++ +1781:: PS:: Using the OSI Directory to Achieve User Friendly Naming +1714:: I:: Referral Whois Protocol (RWhois) +1684:: I:: Introduction to White Pages services based on X.500 +1637:: E:: DNS NSAP Resource Records +1632:: I:: A Revised Catalog of Available X.500 Implementations +1617:: I:: Naming and Structuring Guidelines for X.500 Directory Pilots +1609:: E:: Charting Networks in the X.500 Directory +1608:: E:: Representing IP Information in the X.500 Directory +1588:: I:: WHITE PAGES MEETING REPORT +1562:: I:: Naming Guidelines for the AARNet X.500 Directory Service +1491:: I:: A Survey of Advanced Usages of X.500 +1488:: PS:: The X.500 String Representation of Standard Attribute + Syntaxes +1487:: PS:: X.500 Lightweight Directory Access Protocol +1485:: PS:: A String Representation of Distinguished Names +1484:: E:: Using the OSI Directory to achieve User Friendly Naming +1430:: I:: A Strategic Plan for Deploying an Internet X.500 + Directory Service +1400:: I:: Transition and Modernization of the Internet Registration + Service +1384:: I:: Naming Guidelines for Directory Pilots +1355:: I:: Privacy and Accuracy Issues in Network Information + Center Databases +1330:: I:: Recommendations for the Phase I Deployment of OSI + Directory Services (X.500) and OSI Message Handling + Services (X.400) within the ESnet Community +1309:: I:: Technical Overview of Directory Services Using the + X.500 Protocol +1308:: I:: Executive Introduction to Directory Services Using the + X.500 Protocol +1292:: I:: A Catalog of Available X.500 Implementations +1279:: :: X.500 and Domains +1276:: PS:: Replication and Distributed Operations extensions to + provide an Internet Directory using X.500 +1275:: I:: Replication Requirements to provide an Internet Directory + using X.500 +1274:: PS:: The COSINE and Internet X.500 Schema +1255:: I:: A Naming Scheme for c=US +1218:: :: A Naming Scheme for c=US +1202:: I:: Directory Assistance Service +1107:: :: Plan for Internet directory services + 954:: DS:: NICNAME/WHOIS + 953:: H:: Hostname Server + 812:: :: NICNAME/WHOIS + 756:: :: NIC name server - a datagram-based information utility + 752:: :: Universal host table +============ ========================================================== +Disk Sharing +1813:: I:: NFS Version 3 Protocol Specification +1094:: H:: NFS: Network File System Protocol specification +============ ========================================================== +Games and Chat +1459:: E:: Internet Relay Chat Protocol +====================================================================== +Information Services & File Transfer +2122:: PS:: VEMMI URL Specification +2070:: PS:: Internationalization of the Hypertext Markup Language +2068:: PS:: Hypertext Transfer Protocol -- HTTP/1.1 +2056:: PS:: Uniform Resource Locators for Z39.50 +2055:: I:: WebNFS Server Specification +2054:: I:: WebNFS Client Specification +2044:: I:: "UTF-8, a transformation format of Unicode and ISO 10646" +2016:: E:: Uniform Resource Agents (URAs) +1986:: E:: Experiments with a Simple File Transfer Protocol for + Radio Links using Enhanced Trivial File Transfer + Protocol (ETFTP) +1980:: I:: A Proposed Extension to HTML: Client-Side Image Maps +1960:: PS:: A String Representation of LDAP Search Filters +1959:: PS:: An LDAP URL Format +1945:: I:: Hypertext Transfer Protocol -- HTTP/1.0 +1942:: E:: HTML Tables +1874:: E:: SGML Media Types +1867:: E:: Form-based File Upload in HTML +1866:: PS:: Hypertext Markup Language - 2.0 +1865:: I:: EDI Meets the Internet: Frequently Asked Questions + about Electronic Data Interchange (EDI) on the Internet +1862:: I:: "Report of the IAB Workshop on Internet Information + Infrastructure, October 12-14, 1994" +1843:: I:: HZ - A Data Format for Exchanging Files of Arbitrarily + Mixed Chinese and ASCII characters +1842:: I:: ASCII Printable Characters-Based Chinese Character + Encoding for Internet Messages +1823:: I:: The LDAP Application Program Interface +1815:: I:: Character Sets ISO-10646 and ISO-10646-J-1 +1808:: PS:: Relative Uniform Resource Locators +1807:: I:: A Format for Bibliographic Records +1798:: PS:: Connection-less Lightweight Directory Access Protocol +1788:: E:: ICMP Domain Name Messages +1785:: I:: TFTP Option Negotiation Analysis +1784:: PS:: TFTP Timeout Interval and Transfer Size Options +1783:: PS:: TFTP Blocksize Option +1782:: PS:: TFTP Option Extension +1779:: DS:: A String Representation of Distinguished Names +1778:: DS:: The String Representation of Standard Attribute Syntaxes +1777:: DS:: Lightweight Directory Access Protocol +1766:: PS:: Tags for the Identification of Languages +1738:: PS:: Uniform Resource Locators (URL) +1737:: I:: Functional Requirements for Uniform Resource Names +1736:: I:: Functional Requirements for Internet Resource Locators +1729:: I:: Using the Z39.50 Information Retrieval Protocol in the + Internet Environment +1728:: I:: Resource Transponders +1727:: I:: A Vision of an Integrated Internet Information Service +1639:: E:: FTP Operation Over Big Address Records (FOOBAR) +1633:: I:: Integrated Services in the Internet Architecture +1630:: I:: Universal Resource Identifiers in WWW +1625:: I:: WAIS over Z39.50-1988 +1558:: I:: A String Representation of LDAP Search Filters +1554:: I:: ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP +1545:: E:: FTP Operation Over Big Address Records (FOOBAR) +1530:: I:: Principles of Operation for the TPC.INT Subdomain: + General Principles and Policy +1529:: I:: Principles of Operation for the TPC.INT Subdomain: + Remote Printing -- Administrative Policies +1528:: E:: Principles of Operation for the TPC.INT Subdomain: + Remote Printing -- Technical Procedures +1489:: I:: Registration of a Cyrillic Character Set +1486:: E:: An Experiment in Remote Printing +1440:: E:: SIFT/UFT: Sender-Initiated/Unsolicited File Transfer +1436:: I:: The Internet Gopher Protocol (a distributed document + search and retrieval protocol) +1415:: PS:: FTP-FTAM Gateway Specification +1413:: PS:: Identification Protocol +1350:: S:: THE TFTP PROTOCOL (REVISION 2) +1345:: I:: Character Mnemonics & Character Sets +1312:: E:: Message Send Protocol +1302:: I:: Building a Network Information Services Infrastructure +1288:: DS:: The Finger User Information Protocol +1278:: I:: A String Encoding of Presentation Address +1241:: E:: A Scheme for an Internet Encapsulation Protocol: Version 1 +1235:: E:: The Coherent File Distribution Protocol +1196:: DS:: The Finger User Information Protocol +1194:: DS:: The Finger User Information Protocol +1179:: I:: Line Printer Daemon Protocol +1123:: S:: Requirements for Internet hosts - application and support +1068:: :: Background File Transfer Program BFTP +1037:: H:: NFILE - a file access protocol +1003:: :: Issues in defining an equations representation standard + 998:: E:: NETBLT: A bulk data transfer protocol + 978:: :: Voice File Interchange Protocol VFIP + 971:: :: Survey of data representation standards + 969:: :: NETBLT: A bulk data transfer protocol + 965:: :: Format for a graphical communication protocol + 959:: S:: File Transfer Protocol + 949:: :: FTP unique-named store command + 916:: H:: Reliable Asynchronous Transfer Protocol RATP + 913:: H:: Simple File Transfer Protocol + 887:: E:: Resource Location Protocol + 866:: S:: Active users + 865:: S:: Quote of the Day Protocol + 864:: S:: Character Generator Protocol + 863:: S:: Discard Protocol + 862:: S:: Echo Protocol + 797:: :: Format for Bitmap files + 795:: :: Service mappings + 783:: DS:: TFTP Protocol revision 2 + 775:: :: Directory oriented FTP commands + 765:: :: File Transfer Protocol specification + 751:: :: Survey of FTP mail and MLFL + 743:: :: FTP extension: XRSQ/XRCP + 742:: PS:: NAME/FINGER Protocol + 740:: H:: NETRJS Protocol + 737:: :: FTP extension: XSEN + 725:: :: RJE protocol for a resource sharing network + 722:: :: Thoughts on interactions in distributed services + 712:: :: Distributed Capability Computing System DCCS + 707:: :: High-level framework for network-based resource sharing + 697:: :: CWD command of FTP + 691:: :: One more try on the FTP + 683:: :: FTPSRV - Tenex extension for paged files + 662:: :: Performance improvement in ARPANET file transfers + from Multics + 640:: :: Revised FTP reply codes + 633:: :: IMP/TIP preventive maintenance schedule + 630:: :: FTP error code usage for more reliable mail service + 624:: :: Comments on the File Transfer Protocol + 622:: :: Scheduling IMP/TIP down time + 614:: :: "Response to RFC 607: ""Comments on the File Transfer + Protocol""" + 610:: :: Further datalanguage design concepts + 607:: :: Comments on the File Transfer Protocol + 599:: :: Update on NETRJS + 593:: :: Telnet and FTP implementation schedule change + 592:: :: Some thoughts on system design to facilitate resource + sharing + 589:: :: CCN NETRJS server messages to remote user + 573:: :: Data and file transfer: Some measurement results + 571:: :: Tenex FTP problem + 570:: :: Experimental input mapping between NVT ASCII and UCSB + On Line System + 553:: :: Draft design for a text/graphics protocol + 551:: :: "[Letter from Feinroth re: NYU, ANL, and LBL entering + the net, and FTP protocol]" + 549:: :: "Minutes of Network Graphics Group meeting, 15-17 + July 1973" + 543:: :: Network journal submission and delivery + 542:: :: File Transfer Protocol + 535:: :: Comments on File Access Protocol + 532:: :: UCSD-CC Server-FTP facility + 525:: :: MIT-MATHLAB meets UCSB-OLS -an example of resource sharing + 520:: :: Memo to FTP group: Proposal for File Access Protocol + 514:: :: Network make-work + 506:: :: FTP command naming problem + 505:: :: Two solutions to a file transfer access problem + 504:: :: Distributed resources workshop announcement + 501:: :: "Un-muddling ""free file transfer""" + 499:: :: Harvard's network RJE + 493:: :: "E.W., Jr Graphics Protocol" + 490:: :: Surrogate RJS for UCLA-CCN + 487:: :: Free file transfer + 486:: :: Data transfer revisited + 485:: :: MIX and MIXAL at UCSB + 480:: :: Host-dependent FTP parameters + 479:: :: Use of FTP by the NIC Journal + 478:: :: FTP server-server interaction - II + 477:: :: Remote Job Service at UCSB + 472:: :: Illinois' reply to Maxwell's request for graphics + information NIC 14925 + 468:: :: FTP data compression + 467:: :: Proposed change to Host-Host Protocol:Resynchronization + of connection status + 463:: :: FTP comments and response to RFC 430 + 454:: :: File Transfer Protocol - meeting announcement and a new + proposed document + 451:: :: Tentative proposal for a Unified User Level Protocol + 448:: :: Print files in FTP + 446:: :: Proposal to consider a network program resource notebook + 438:: :: FTP server-server interaction + 437:: :: Data Reconfiguration Service at UCSB + 436:: :: Announcement of RJS at UCSB + 430:: :: Comments on File Transfer Protocol + 429:: :: Character generator process + 418:: :: Server file transfer under TSS/360 at NASA Ames + 414:: :: File Transfer Protocol FTP status and further comments + 412:: :: User FTP documentation + 411:: :: New MULTICS network software features + 410:: :: Removal of the 30-second delay when hosts come up + 409:: :: Tenex interface to UCSB's Simple-Minded File System + 407:: H:: Remote Job Entry Protocol + 406:: :: Scheduled IMP software releases + 396:: :: Network Graphics Working Group meeting - second iteration + 387:: :: Some experiences in implementing Network Graphics + Protocol Level 0 + 385:: :: Comments on the File Transfer Protocol + 382:: :: Mathematical software on the ARPA Network + 374:: :: IMP system announcement + 373:: :: Arbitrary character sets + 368:: :: "Comments on ""Proposed Remote Job Entry Protocol""" + 367:: :: Network host status + 366:: :: Network host status + 361:: :: Deamon processes on host 106 + 360:: :: Proposed Remote Job Entry Protocol + 354:: :: File Transfer Protocol + 351:: :: Graphics information form for the ARPANET graphics + resources notebook + 342:: :: Network host status + 338:: :: EBCDIC/ASCII mapping for network RJE + 336:: :: Level 0 Graphic Input Protocol + 335:: :: New interface - IMP/360 + 332:: :: Network host status + 325:: :: Network Remote Job Entry program - NETRJS + 324:: :: RJE Protocol meeting + 314:: :: Network Graphics Working Group meeting + 310:: :: Another look at Data and File Transfer Protocols + 309:: :: Data and File Transfer workshop announcement + 307:: :: Using network Remote Job Entry + 306:: :: Network host status + 299:: :: Information management system + 298:: :: Network host status + 294:: :: "On the use of ""set data type"" transaction in + File Transfer Protocol" + 293:: :: Network host status + 292:: :: "E.W., Jr Graphics Protocol: Level 0 only" + 288:: :: Network host status + 287:: :: Status of network hosts + 286:: :: Network library information system + 285:: :: Network graphics + 283:: :: NETRJT: Remote Job Service Protocol for TIPS + 281:: :: Suggested addition to File Transfer Protocol + 268:: :: Graphics facilities information + 267:: :: Network host status + 266:: :: Network host status + 265:: :: "File Transfer Protocol" + 264:: :: "Data Transfer Protocol" + 255:: :: Status of network hosts + 252:: :: Network host status + 250:: :: Some thoughts on file transfer + 238:: :: Comments on DTP and FTP proposals + 217:: :: "Specifications changes for OLS, RJE/RJOR, and SMFS" + 199:: :: Suggestions for a network data-tablet graphics protocol + 192:: :: Some factors which a Network Graphics Protocol must + consider + 191:: :: Graphics implementation and conceptualization at + Augmentation Research Center + 189:: :: Interim NETRJS specifications + 184:: :: Proposed graphic display modes + 183:: :: EBCDIC codes and their mapping to ASCII + 181:: :: Modifications to RFC 177 + 174:: :: UCLA - computer science graphics overview + 172:: :: File Transfer Protocol + 163:: :: Data transfer protocols + 141:: :: Comments on RFC 114: A File Transfer Protocol + 134:: :: Network Graphics meeting + 133:: :: File transfer and recovery + 125:: :: Response to RFC 86: Proposal for network standard format + for a graphics data stream + 114:: :: File Transfer Protocol + 105:: :: Network specifications for Remote Job Entry and Remote + Job Output Retrieval at UCSB + 98:: :: Logger Protocol proposal + 94:: :: Some thoughts on network graphics + 88:: :: NETRJS: A third level protocol for Remote JobEntry + 86:: :: Proposal for a network standard format for a data stream + to control graphics display + 83:: :: Language-machine for data reconfiguration + ========== ============================================================ + Internet & Network Layer +2126:: PS:: ISO Transport Service on top of TCP (ITOT) +2125:: PS:: The PPP Bandwidth Allocation Protocol (BAP) The PPP + Bandwidth Allocation Control Protocol (BACP) +2118:: I:: Microsoft Point-To-Point Compression (MPPC) Protocol +2114:: I:: Data Link Switching Client Access Protocol +2113:: PS:: IP Router Alert Option +2107:: I:: Ascend Tunnel Management Protocol - ATMP +2106:: I:: Data Link Switching Remote Access Protocol +2105:: I:: Cisco Systems' Tag Switching Architecture Overview +2098:: I:: Toshiba's Router Architecture Extensions for ATM:Overview +2097:: PS:: The PPP NetBIOS Frames Control Protocol (NBFCP) +2075:: I:: IP Echo Host Service +2067:: DS:: IP over HIPPI +2043:: PS:: The PPP SNA Control Protocol (SNACP) +2023:: PS:: IP Version 6 over PPP +2019:: PS:: Transmission of IPv6 Packets Over FDDI +2018:: PS:: TCP Selective Acknowledgment Options +2009:: E:: GPS-Based Addressing and Routing +2005:: PS:: Applicability Statement for IP Mobility Support +2004:: PS:: Minimal Encapsulation within IP +2003:: PS:: IP Encapsulation within IP +2002:: PS:: IP Mobility Support +2001:: PS:: "TCP Slow Start, Congestion Avoidance, Fast Retransmit, + and Fast Recovery Algorithms" +1994:: DS:: PPP Challenge Handshake Authentication Protocol (CHAP) +1993:: I:: PPP Gandalf FZA Compression Protocol +1990:: DS:: The PPP Multilink Protocol (MP) +1989:: DS:: PPP Link Quality Monitoring +1981:: PS:: Path MTU Discovery for IP version 6 +1979:: I:: PPP Deflate Protocol +1978:: I:: PPP Predictor Compression Protocol +1977:: I:: PPP BSD Compression Protocol +1976:: I:: PPP for Data Compression in Data Circuit-Terminating + Equipment (DCE) +1975:: I:: PPP Magnalink Variable Resource Compression +1974:: I:: PPP Stac LZS Compression Protocol +1973:: PS:: PPP in Frame Relay +1972:: PS:: A Method for the Transmission of IPv6 Packets over + Ethernet Networks +1967:: I:: PPP LZS-DCP Compression Protocol (LZS-DCP) +1963:: I:: PPP Serial Data Transport Protocol (SDTP) +1962:: PS:: The PPP Compression Control Protocol (CCP) +1954:: I:: Transmission of Flow Labelled IPv4 on ATM Data Links + Ipsilon Version 1.0 +1946:: I:: Native ATM Support for ST2+ +1937:: I:: Local/Remote Forwarding Decision in Switched Data + Link Subnetworks +1936:: I:: Implementing the Internet Checksum in Hardware +1934:: I:: Ascend's Multilink Protocol Plus (MP+) +1933:: PS:: Transition Mechanisms for IPv6 Hosts and Routers +1932:: I:: IP over ATM: A Framework Document +1931:: I:: Dynamic RARP Extensions and Administrative Support for + Automatic Network Address Allocation +1926:: I:: An Experimental Encapsulation of IP Datagrams on + Top of ATM +1924:: I:: A Compact Representation of IPv6 Addresses +1919:: I:: Classical versus Transparent IP Proxies +1918:: BC:: Address Allocation for Private Internets +1917:: BC:: An Appeal to the Internet Community to Return Unused + IP Networks (Prefixes) to the IANA +1916:: I:: Enterprise Renumbering +1915:: BC:: Variance for The PPP Connection Control Protocol and + The PPP Encryption Control Protocol +1897:: E:: IPv6 Testing Address Allocation +1888:: E:: OSI NSAPs and IPv6 +1887:: I:: An Architecture for IPv6 Unicast Address Allocation +1885:: PS:: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) +1884:: PS:: IP Version 6 Addressing Architecture +1883:: PS:: "Internet Protocol, Version 6 (IPv6) Specification" +1881:: I:: IPv6 Address Allocation Management +1878:: I:: Variable Length Subnet Table For IPv4 +1877:: I:: PPP Internet Protocol Control Protocol Extensions for + Name Server Addresses +1868:: E:: ARP Extension - UNARP +1860:: I:: Variable Length Subnet Table For IPv4 +1859:: I:: ISO Transport Class 2 Non-use of Explicit Flow Control + over TCP RFC1006 extension +1853:: I:: IP in IP Tunneling +1841:: I:: PPP Network Control Protocol for LAN Extension +1833:: PS:: Binding Protocols for ONC RPC Version 2 +1832:: PS:: XDR +1831:: PS:: RPC +1809:: I:: Using the Flow Label Field in IPv6 +1795:: I:: "Data Link Switching +1791:: E:: TCP And UDP Over IPX Networks With Fixed Path MTU +1770:: I:: IPv4 Option for Sender Directed Multi-Destination Delivery +1764:: PS:: The PPP XNS IDP Control Protocol (XNSCP) +1763:: PS:: The PPP Banyan Vines Control Protocol (BVCP) +1762:: DS:: The PPP DECnet Phase IV Control Protocol (DNCP) +1761:: I:: Snoop Version 2 Packet Capture File Format +1756:: E:: REMOTE WRITE PROTOCOL - VERSION 1.0 +1755:: PS:: ATM Signaling Support for IP over ATM +1754:: I:: IP over ATM Working Group's Recommendations for the + ATM Forum's Multiprotocol BOF Version 1 +1752:: PS:: The Recommendation for the IP Next Generation Protocol +1744:: I:: Observations on the Management of the Internet Address + Space +1735:: E:: NBMA Address Resolution Protocol (NARP) +1726:: I:: Technical Criteria for Choosing IP +1719:: I:: A Direction for IPng +1717:: PS:: The PPP Multilink Protocol (MP) +1710:: I:: Simple Internet Protocol Plus White Paper +1707:: I:: CATNIP +1705:: I:: Six Virtual Inches to the Left +1698:: I:: Octet Sequences for Upper-Layer OSI to Support Basic + Communications Applications +1693:: E:: An Extension to TCP +1692:: PS:: Transport Multiplexing Protocol (TMux) +1688:: I:: IPng Mobility Considerations +1687:: I:: A Large Corporate User's View of IPng +1686:: I:: IPng Requirements +1683:: I:: Multiprotocol Interoperability In IPng +1682:: I:: IPng BSD Host Implementation Analysis +1681:: I:: On Many Addresses per Host +1680:: I:: IPng Support for ATM Services +1679:: I:: HPN Working Group Input to the IPng Requirements + Solicitation +1678:: I:: IPng Requirements of Large Corporate Networks +1677:: I:: Tactical Radio Frequency Communication Requirements + for IPng +1676:: I:: INFN Requirements for an IPng +1674:: I:: A Cellular Industry View of IPng +1673:: I:: Electric Power Research Institute Comments on IPng +1672:: I:: Accounting Requirements for IPng +1671:: I:: IPng White Paper on Transition and Other Considerations +1670:: I:: Input to IPng Engineering Considerations +1669:: I:: Market Viability as a IPng Criteria +1667:: I:: Modeling and Simulation Requirements for IPng +1663:: PS:: PPP Reliable Transmission +1662:: S:: PPP in HDLC-like Framing +1661:: S:: The Point-to-Point Protocol (PPP) +1644:: E:: T/TCP -- TCP Extensions for Transactions Functional + Specification +1638:: PS:: PPP Bridging Control Protocol (BCP) +1634:: I:: Novell IPX Over Various WAN Media (IPXWAN) +1631:: I:: The IP Network Address Translator (Nat) +1629:: DS:: Guidelines for OSI NSAP Allocation in the Internet +1626:: PS:: Default IP MTU for use over ATM AAL5 +1624:: I:: Computation of the Internet Checksum via Incremental + Update +1622:: I:: Pip Header Processing +1621:: I:: Pip Near-term Architecture +1620:: I:: Internet Architecture Extensions for Shared Media +1619:: PS:: PPP over SONET/SDH +1618:: PS:: PPP over ISDN +1613:: I:: cisco Systems X.25 over TCP (XOT) +1605:: I:: SONET to Sonnet Translation +1604:: PS:: Definitions of Managed Objects for Frame Relay Service +1598:: PS:: PPP in X.25 +1590:: I:: Media Type Registration Procedure +1577:: PS:: Classical IP and ARP over ATM +1575:: DS:: An Echo Function for CLNP (ISO 8473) +1570:: PS:: PPP LCP Extensions +1561:: E:: Use of ISO CLNP in TUBA Environments +1560:: I:: The MultiProtocol Internet +1553:: PS:: Compressing IPX Headers Over WAN Media (CIPX) +1552:: PS:: The PPP Internetwork Packet Exchange Control + Protocol (IPXCP) +1551:: I:: Novell IPX Over Various WAN Media (IPXWAN) +1549:: DS:: PPP in HDLC Framing +1548:: DS:: The Point-to-Point Protocol (PPP) +1547:: I:: Requirements for an Internet Standard + Point-to-Point Protocol +1538:: I:: Advanced SNA/IP +1526:: I:: Assignment of System Identifiers for TUBA/CLNP Hosts +1518:: PS:: An Architecture for IP Address Allocation with CIDR +1498:: I:: On the Naming and Binding of Network Destinations +1490:: DS:: Multiprotocol Interconnect over Frame Relay +1483:: PS:: Multiprotocol Encapsulation over ATM Adaptation Layer 5 +1475:: E:: TP/IX +1466:: I:: Guidelines for Management of IP Address Space +1454:: I:: Comparison of Proposals for Next Version of IP +1435:: I:: IESG Advice from Experience with Path MTU Discovery +1434:: I:: Data Link Switching +1433:: E:: Directed ARP +1393:: E:: Traceroute Using an IP Option +1390:: S:: Transmission of IP and ARP over FDDI Networks +1385:: I:: EIP +1379:: I:: Extending TCP for Transactions -- Concepts +1378:: PS:: The PPP AppleTalk Control Protocol (ATCP) +1377:: PS:: The PPP OSI Network Layer Control Protocol (OSINLCP) +1376:: PS:: The PPP DECnet Phase IV Control Protocol (DNCP) +1375:: I:: Suggestion for New Classes of IP Addresses +1374:: PS:: IP and ARP on HIPPI +1365:: I:: An IP Address Extension Proposal +1363:: E:: A Proposed Flow Specification +1362:: I:: Novell IPX Over Various WAN Media (IPXWAN) +1356:: PS:: Multiprotocol Interconnect on X.25 and ISDN in the + Packet Mode +1347:: I:: "TCP and UDP with Bigger Addresses (TUBA), A Simple + Proposal for Internet Addressing and Routing" +1337:: I:: TIME-WAIT Assassination Hazards in TCP +1335:: :: A Two-Tier Address Structure for the Internet +1334:: PS:: PPP Authentication Protocols +1333:: PS:: PPP Link Quality Monitoring +1332:: PS:: The PPP Internet Protocol Control Protocol (IPCP) +1331:: PS:: The Point-to-Point Protocol (PPP) for the Transmission + of Multi-protocol Datagrams over Point-to-Point Links +1329:: I:: Thoughts on Address Resolution for Dual MAC FDDI Networks +1326:: I:: Mutual Encapsulation Considered Dangerous +1323:: PS:: TCP Extensions for High Performance +1314:: PS:: A File Format for the Exchange of Images in the Internet +1307:: E:: Dynamically Switched Link Control Protocol +1306:: I:: Experiences Supporting By-Request Circuit-Switched T3 + Networks +1294:: PS:: Multiprotocol Interconnect over Frame Relay +1293:: PS:: Inverse Address Resolution Protocol +1277:: PS:: Encoding Network Addresses to Support Operation Over + Non-OSI Lower Layers +1263:: I:: TCP Extensions Considered Harmful +1256:: PS:: ICMP Router Discovery Messages +1240:: PS:: OSI Connectionless Transport Services on top of UDP +1237:: PS:: Guidelines for OSI NSAP Allocation in the Internet +1236:: :: IP to X.121 Address Mapping for DDN +1234:: PS:: Tunneling IPX Traffic through IP Networks +1226:: E:: Internet Protocol Encapsulation of AX.25 Frames +1223:: :: OSI CLNS and LLC1 Protocols on Network Systems HYPERchannel +1220:: PS:: Point-to-Point Protocol Extensions for Bridging +1219:: :: On the Assignment of Subnet Numbers +1210:: :: "Network and Infrastructure User Requirements for + Transatlantic Research Collaboration - Brussels, + July 16-18, and Washington July 24-25, 1990" +1209:: DS:: The Transmission of IP Datagrams over the SMDS Service +1201:: H:: Transmitting IP Traffic over ARCNET Networks +1191:: DS:: Path MTU Discovery +1188:: DS:: A Proposed Standard for the Transmission of IP Datagrams + over FDDI Networks +1185:: E:: TCP Extension for High-Speed Paths +1172:: PS:: The Point-to-Point Protocol (PPP) Initial Configuration + Options +1171:: DS:: The Point-to-Point Protocol for the Transmission of + Multi-Protocol Datagrams Over Point-to-Point Links +1166:: :: Internet Numbers +1162:: :: Connectionless Network Protocol (ISO 8473) and End + System to Intermediate System (ISO 9542) Management + Information Base +1151:: E:: Version 2 of the Reliable Data Protocol (RDP) +1146:: E:: TCP Alternate Checksum Options +1145:: E:: TCP Alternate Checksum Options +1144:: PS:: Compressing TCP/IP headers for low-speed serial links +1141:: :: Incremental Updating of the Internet Checksum +1139:: PS:: Echo function for ISO 8473 +1134:: PS:: Point-to-Point Protocol +1132:: S:: Standard for the transmission of 802.2 packets over + IPX networks +1122:: S:: Requirements for Internet hosts - communication layers +1110:: :: Problem with the TCP big window option +1106:: :: TCP big window and NAK options +1103:: PS:: Proposed standard for the transmission of IP datagrams + over FDDI Networks +1088:: S:: Standard for the transmission of IP datagrams over + NetBIOS networks +1086:: :: ISO-TP0 bridge between TCP and X.25 +1085:: :: ISO presentation services on top of TCP/IP based internets +1078:: :: TCP port service Multiplexer TCPMUX +1072:: E:: TCP extensions for long-delay paths +1071:: :: Computing the Internet checksum +1070:: :: Use of the Internet as a subnetwork for experimentation + with the OSI network layer +1069:: :: Guidelines for the use of Internet-IP addressesin the + ISO Connectionless-Mode Network Protocol +1063:: :: IP MTU Discovery options +1062:: :: Internet numbers +1057:: I:: RPC +1055:: S:: Nonstandard for transmission of IP datagrams over serial + lines +1051:: S:: Standard for the transmission of IP datagrams and ARP + packets over ARCNET networks +1050:: H:: RPC +1046:: :: Queuing algorithm to provide type-of-service for IP links +1045:: E:: VMTP +1044:: S:: Internet Protocol on Network System's HYPERchannel +1042:: S:: Standard for the transmission of IP datagrams over + IEEE 802 networks +1030:: :: On testing the NETBLT Protocol over divers networks +1029:: :: More fault tolerant approach to address resolution for + a Multi-LAN system of Ethernets +1027:: :: Using ARP to implement transparent subnet gateways +1025:: :: TCP and IP bake off +1016:: :: Something a host could do with source quench +1008:: :: Implementation guide for the ISO Transport Protocol +1007:: :: Military supplement to the ISO Transport Protocol +1006:: S:: ISO transport services on top of the TCP +1002:: S:: Protocol standard for a NetBIOS service on a TCP/UDP + transport +1001:: S:: Protocol standard for a NetBIOS service on a TCP/UDP + transport + 994:: :: "Final text of DIS 8473,Protocol for Providing the + Connectionless-mode Network Service" + 986:: :: Guidelines for the use of Internet-IP addressesin the + ISO Connectionless-Mode Network Protocol [Working draft] + 983:: :: ISO transport arrives on top of the TCP + 982:: :: Guidelines for the specification of the structure of the + Domain Specific Part DSP of the ISO standard NSAP address + 970:: :: On packet switches with infinite storage + 964:: :: Some problems with the specification of the Military + Standard Transmission Control Protocol + 963:: :: Some problems with the specification of the Military + Standard Internet Protocol + 962:: :: TCP-4 prime + 955:: :: Towards a transport service for transaction processing + applications + 948:: :: Two methods for the transmission of IP datagrams over + IEEE 802.3 networks + 942:: :: Transport protocols for Department of Defense data + networks + 941:: :: Addendum to the networkservice definition covering + network layer addressing + 940:: :: Toward an Internet standard scheme for subnetting + 936:: :: Another Internet subnet addressing scheme + 935:: :: Reliable link layer protocols + 932:: :: Subnetwork addressing scheme + 926:: :: Protocol for providing the connectionless mode network + services + 925:: :: Multi-LAN address resolution + 924:: :: Official ARPA-Internet protocols for connecting + personal computers to the Internet + 922:: S:: Broadcasting Internet datagrams in the presence of subnets + 919:: S:: Broadcasting Internet datagrams + 917:: :: Internet subnets + 914:: H:: Thinwire protocol for connecting personal computers to + the Internet + 905:: :: ISO Transport Protocol specification ISO DP 8073 + 903:: S:: Reverse Address Resolution Protocol + 896:: :: Congestion control in IP/TCP internetworks + 895:: S:: Standard for the transmission of IP datagrams over + experimental Ethernet networks + 894:: S:: Standard for the transmission of IP datagrams over + Ethernet networks + 893:: :: Trailer encapsulations + 892:: :: ISO Transport Protocol specification [Draft] + 891:: S:: DCN local-network protocols + 889:: :: Internet delay experiments + 879:: :: TCP maximum segment size and related topics + 877:: S:: Standard for the transmission of IP datagrams over + public data networks + 874:: :: Critique of X.25 + 872:: :: TCP-on-a-LAN + 871:: :: Perspective on the ARPANET reference model + 848:: :: "Who provides the ""little"" TCP services?" + 829:: :: Packet satellite technology reference sources + 826:: S:: Ethernet Address Resolution Protocol + 824:: :: CRONUS Virtual Local Network + 815:: :: IP datagram reassembly algorithms + 814:: :: "Name, addresses, ports, and routes" + 813:: :: Window and acknowlegement strategy in TCP + 801:: :: NCP/TCP transition plan + 793:: S:: Transmission Control Protocol + 792:: S:: Internet Control Message Protocol + 791:: S:: Internet Protocol + 789:: :: Vulnerabilities of network control protocols + 787:: :: Connectionless data transmission survey/tutorial + 781:: :: Specification of the Internet Protocol IP timestamp option + 777:: :: Internet Control Message Protocol + 768:: S:: User Datagram Protocol + 761:: :: DOD Standard Transmission Control Protocol + 760:: :: DoD standard Internet Protocol + 759:: H:: Internet Message Protocol + 730:: :: Extensible field addressing + 704:: :: IMP/Host and Host/IMP Protocol change + 696:: :: Comments on the IMP/Host and Host/IMP Protocol changes + 695:: :: Official change in Host-Host Protocol + 692:: :: Comments on IMP/Host Protocol changes RFCs 687 and 690 + 690:: :: Comments on the proposed Host/IMP Protocol changes + 689:: :: Tenex NCP finite state machine for connections + 687:: :: IMP/Host and Host/IMP Protocol changes + 685:: :: Response time in cross network debugging + 680:: :: Message Transmission Protocol + 675:: :: Specification of Internet Transmission Control Program + 674:: :: Procedure call documents - version 2 + 660:: :: Some changes to the IMP and the IMP/Host interface + 632:: :: Throughput degradations for single packet messages + 626:: :: On a possible lockup condition in IMP subnet due to + message sequencing + 613:: :: Network connectivity + 611:: :: Two changes to the IMP/Host Protocol to improve + user/network communications + 594:: :: Speedup of Host-IMP interface + 591:: :: Addition to the Very Distant Host specifications + 576:: :: Proposal for modifying linking + 550:: :: NIC NCP experiment + 548:: :: Hosts using the IMP Going Down message + 528:: :: Software checksumming in the IMP and network reliability + 521:: :: Restricted use of IMP DDT + 489:: :: Comment on resynchronization of connection status proposal + 488:: :: NLS classes at network sites + 476:: :: IMP/TIP memory retrofit schedule rev. 2 + 473:: :: MIX and MIXAL? + 460:: :: NCP survey + 459:: :: Network questionnaires + 450:: :: MULTICS sampling timeout change + 449:: :: Current flow-control scheme for IMPSYS + 445:: :: IMP/TIP preventive maintenance schedule + 442:: :: Current flow-control scheme for IMPSYS + 434:: :: IMP/TIP memory retrofit schedule + 426:: :: Reconnection Protocol + 417:: :: Link usage violation + 398:: :: ICP sockets + 395:: :: Switch settings on IMPs and TIPs + 394:: :: Two proposed changes to the IMP-Host Protocol + 359:: :: Status of the release of the new IMP System + 357:: :: Echoing strategy for satellite links + 348:: :: Discard process + 347:: :: Echo process + 346:: :: Satellite considerations + 343:: :: IMP System change notification + 312:: :: Proposed change in IMP-to-Host Protocol + 301:: :: "BBN IMP #5 and NCC schedule March 4, 1971" + 300:: :: ARPA Network mailing lists + 271:: :: IMP System change notifications + 241:: :: Connecting computers to MLC ports + 210:: :: Improvement of flow control + 203:: :: Achieving reliable communication + 202:: :: Possible deadlock in ICP + 197:: :: Initial Connection Protocol - Reviewed + 190:: :: DEC PDP-10-IMLAC communications system + 178:: :: Network graphic attention handling + 176:: :: "Comments on ""Byte size for connections""" + 175:: :: "Comments on ""Socket conventions reconsidered""" + 166:: :: Data Reconfiguration Service + 165:: :: Proffered official Initial Connection Protocol + 161:: :: Solution to the race condition in the ICP + 151:: :: "Comments on a proffered official ICP + 150:: :: Use of IPC facilities + 146:: :: Views on issues relevant to data sharing on computer + networks + 145:: :: Initial Connection Protocol control commands + 143:: :: Regarding proffered official ICP + 142:: :: Time-out mechanism in the Host-Host Protocol + 128:: :: Bytes + 127:: :: Comments on RFC 123 + 123:: :: Proffered official ICP + 122:: :: Network specifications for UCSB's Simple-Minded File + System + 93:: :: Initial Connection Protocol + 91:: :: Proposed User-User Protocol + 80:: :: Protocols and data formats + 79:: :: Logger Protocol error + 70:: :: Note on padding + 67:: :: Proposed change to Host/IMP spec to eliminate marking + 65:: :: Comments on Host/Host Protocol document #1 + 62:: :: Systems for interprocess communication in a resource + sharing computer network + 60:: :: Simplified NCP Protocol + 59:: :: Flow control - fixed versus demand allocation + 56:: :: Third level protocol + 55:: :: Prototypical implementation of the NCP + 54:: :: Official protocol proffering + 53:: :: Official protocol mechanism + 41:: :: IMP-IMP teletype communication + 38:: :: Comments on network protocol from NWG/RFC #36 + 33:: :: New Host-Host Protocol + 23:: :: Transmission of multiple control messages + 22:: :: Host-host control message formats + 20:: :: ASCII format for network interchange + 19:: :: Two protocol suggestions to reduce congestion at + swap bound nodes + 17:: :: Some questions re + 12:: :: IMP-Host interface flow diagrams +===================================================================== +Mail +2112:: PS:: The MIME Multipart/Related Content-type +2111:: PS:: Content-ID and Message-ID Uniform Resource Locators +2110:: PS:: "MIME E-mail Encapsulation of Aggregate Documents, such + as HTML (MHTML)" +2109:: PS:: HTTP State Management Mechanism +2095:: PS:: IMAP/POP AUTHorize Extension for Simple Challenge/Response +2088:: PS:: IMAP4 non-synchroniziong literals +2087:: PS:: IMAP4 QUOTA extension +2086:: PS:: IMAP4 ACL extension +2077:: PS:: The Model Primary Content Type for Multipurpose + Internet Mail Extensions +2076:: I:: Common Internet Message Headers +2062:: I:: Internet Message Access Protocol - Obsolete Syntax +2061:: I:: IMAP4 COMPATIBILITY WITH IMAP2BIS +2060:: PS:: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 +2049:: DS:: Multipurpose Internet Mail Extensions (MIME) Part Five +2048:: BC:: Multipurpose Internet Mail Extensions (MIME) Part Four +2047:: DS:: MIME (Multipurpose Internet Mail Extensions) Part Three +2046:: DS:: Multipurpose Internet Mail Extensions (MIME) Part Two +2045:: DS:: Multipurpose Internet Mail Extensions (MIME) Part One +2034:: PS:: SMTP Service Extension for Returning Enhanced Error Codes +2033:: I:: Local Mail Transfer Protocol +2017:: PS:: Definition of the URL MIME External-Body Access-Type +1991:: I:: PGP Message Exchange Formats +1985:: PS:: SMTP Service Extension for Remote Message Queue Starting +1957:: I:: Some Observations on Implementations of the Post Office + Protocol (POP3) +1947:: I:: Greek Character Encoding for Electronic Mail Messages +1939:: S:: Post Office Protocol - Version 3 +1927:: I:: Suggested Additional MIME Types for Associating Documents +1922:: I:: Chinese Character Encoding for Internet Messages +1911:: E:: Voice Profile for Internet Mail +1896:: I:: The text/enriched MIME Content-type +1895:: I:: The Application/CALS-1840 Content-type +1894:: PS:: An Extensible Message Format for Delivery Status + Notifications +1893:: PS:: Enhanced Mail System Status Codes +1892:: PS:: The Multipart/Report Content Type for the Reporting + of Mail System Administrative Messages +1891:: PS:: SMTP Service Extension for Delivery Status Notifications +1873:: E:: Message/External-Body Content-ID Access Type +1872:: E:: The MIME Multipart/Related Content-type +1870:: S:: SMTP Service Extension for Message Size Declaration +1869:: S:: SMTP Service Extensions +1864:: DS:: The Content-MD5 Header Field +1854:: PS:: SMTP Service Extension for Command Pipelining +1848:: PS:: MIME Object Security Services +1847:: PS:: Security Multiparts for MIME +1846:: E:: SMTP 521 reply code +1845:: E:: SMTP Service Extension for Checkpoint/Restart +1844:: I:: Multimedia E-mail (MIME) User Agent checklist +1830:: E:: SMTP Service Extensions for Transmission of Large + and Binary MIME Messages +1820:: I:: Multimedia E-mail (MIME) User Agent Checklist +1806:: E:: Communicating Presentation Information in Internet + Messages +1804:: E:: Schema Publishing in X.500 Directory +1803:: I:: Recommendations for an X.500 Production Directory Service +1801:: E:: MHS use of the X.500 Directory to support MHS Routing +1767:: PS:: MIME Encapsulation of EDI Objects +1741:: I:: MIME Content Type for BinHex Encoded Files +1740:: PS:: MIME Encapsulation of Macintosh files - MacMIME +1734:: PS:: POP3 AUTHentication command +1733:: I:: DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4 +1732:: I:: IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS +1731:: PS:: IMAP4 Authentication mechanisms +1730:: PS:: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4 +1725:: DS:: Post Office Protocol - Version 3 +1711:: I:: Classifications in E-mail Routing +1685:: I:: Writing X.400 O/R Names +1653:: DS:: SMTP Service Extension for Message Size Declaration +1652:: DS:: SMTP Service Extension for 8bit-MIMEtransport +1651:: DS:: SMTP Service Extensions +1649:: I:: Operational Requirements for X.400 Management Domains + in the GO-MHS Community +1648:: PS:: Postmaster Convention for X.400 Operations +1642:: E:: UTF-7 - A Mail-Safe Transformation Format of Unicode +1641:: E:: Using Unicode with MIME +1616:: I:: X.400(1988) for the Academic and Research Community + in Europe +1615:: I:: Migrating from X.400(84) to X.400(88) +1563:: I:: The text/enriched MIME Content-type +1557:: I:: Korean Character Encoding for Internet Messages +1556:: I:: Handling of Bi-directional Texts in MIME +1555:: I:: Hebrew Character Encoding for Internet Messages +1544:: PS:: The Content-MD5 Header Field +1524:: I:: A User Agent Configuration Mechanism For Multimedia + Mail Format Information +1523:: I:: The text/enriched MIME Content-type +1522:: DS:: MIME (Multipurpose Internet Mail Extensions) Part Two +1521:: DS:: MIME (Multipurpose Internet Mail Extensions) Part One +1506:: I:: A tutorial on gatewaying between X.400 and Internet mail +1505:: E:: Encoding Header Field for Internet Messages +1502:: PS:: X.400 Use of Extended Character Sets +1496:: PS:: Rules for downgrading messages from X.400/88 to X.400/84 + when MIME content-types are present in the messages +1495:: PS:: Mapping between X.400 and RFC-822 Message Bodies +1494:: PS:: Equivalences between 1988 X.400 and RFC-822 Message Bodies +1468:: I:: Japanese Character Encoding for Internet Messages +1465:: E:: Routing coordination for X.400 MHS services within a + multi protocol / multi network environment Table Format + V3 for static routing +1460:: DS:: Post Office Protocol - Version 3 +1456:: I:: Conventions for Encoding the Vietnamese Language VISCII +1437:: I:: The Extension of MIME Content-Types to a New Medium +1429:: I:: Listserv Distribute Protocol +1428:: I:: Transition of Internet Mail from Just-Send-8 to + 8Bit-SMTP/MIME +1427:: PS:: SMTP Service Extension for Message Size Declaration +1426:: PS:: SMTP Service Extension for 8bit-MIMEtransport +1425:: PS:: SMTP Service Extensions +1405:: E:: Mapping between X.400(1984/1988) and Mail-11 (DECnet mail) +1357:: I:: A Format for E-mailing Bibliographic Records +1344:: I:: Implications of MIME for Internet Mail Gateways +1343:: I:: A User Agent Configuration Mechanism For Multimedia + Mail Format Information +1342:: PS:: Representation of Non-ASCII Text in Internet Message + Headers +1341:: PS:: MIME (Multipurpose Internet Mail Extensions) +1339:: E:: Remote Mail Checking Protocol +1328:: PS:: X.400 1988 to 1984 downgrading +1327:: PS:: Mapping between X.400(1988) / ISO 10021 and RFC 822 +1225:: DS:: Post Office Protocol - Version 3 +1211:: :: Problems with the Maintenance of Large Mailing Lists +1204:: E:: Message Posting Protocol (MPP) +1203:: H:: Interactive Mail Access Protocol - Version 3 +1176:: E:: Interactive Mail Access Protocol - Version 2 +1168:: :: Intermail and Commercial Mail Relay Services +1159:: E:: Message Send Protocol +1154:: E:: Encoding Header Field for Internet Messages +1153:: E:: Digest Message Format +1148:: E:: Mapping between X.400 (1988) / ISO 10021 and RFC 822 +1138:: I:: Mapping between X.400(1988) / ISO 10021 and RFC 822 +1137:: E:: Mapping between full RFC 822 and RFC 822 with restricted + encoding +1090:: :: SMTP on X.25 +1082:: H:: Post Office Protocol - version 3 +1081:: PS:: Post Office Protocol - version 3 +1064:: H:: Interactive Mail Access Protocol +1056:: I:: PCMAIL +1049:: S:: Content-type header field for Internet messages +1047:: :: Duplicate messages and SMTP +1026:: PS:: Addendum to RFC 987 + 993:: :: PCMAIL + 987:: PS:: Mapping between X.400 and RFC 822 + 984:: :: PCMAIL + 976:: :: UUCP mail interchange format standard + 974:: S:: Mail routing and the domain system + 937:: H:: Post Office Protocol - version 2 + 934:: :: Proposed standard for message encapsulation + 918:: :: Post Office Protocol + 915:: :: Network mail path service + 910:: :: Multimedia mail meeting notes + 886:: :: Proposed standard for message header munging + 876:: :: Survey of SMTP implementations + 841:: :: Specification for message format for Computer Based + Message Systems + 822:: S:: Standard for the format of ARPA Internet text messages + 821:: S:: Simple Mail Transfer Protocol + 808:: :: Summary of computer mail services meeting held at BBN + on 10 January 1979 + 807:: :: Multimedia mail meeting notes + 805:: :: Computer mail meeting notes + 788:: :: Simple Mail Transfer Protocol + 786:: :: Mail Transfer Protocol + 785:: :: Mail Transfer Protocol + 784:: :: Mail Transfer Protocol + 780:: :: Mail Transfer Protocol + 773:: :: Comments on NCP/TCP mail service transition strategy + 772:: :: Mail Transfer Protocol + 771:: :: Mail transition plan + 767:: :: Structured format for transmission of multi-media + documents + 763:: :: Role mailboxes + 757:: :: "Suggested solution to the naming, addressing, and delivery problem for ARPANET message systems" + 754:: :: Out-of-net host addresses for mail + 753:: :: Internet Message Protocol + 744:: :: MARS - a Message Archiving and Retrieval Service + 733:: :: Standard for theformat of ARPA network text messages + 724:: :: Proposed official standard for the format of ARPA + Network messages + 720:: :: Address specification syntax for network mail + 714:: :: Host-Host Protocol for an ARPANET-type network + 713:: :: MSDTP-Message Services Data Transmission Protocol + 706:: :: On the junk mail problem + 577:: :: Mail priority + 574:: :: Announcement of a mail facility at UCSB + 561:: :: Standardizingnetwork mail headers + 555:: :: Responses to critiques of the proposed mail protocol + 539:: :: Thoughts on the mail protocol proposed in RFC524 + 534:: :: Lost message detection + 533:: :: Message-ID numbers + 524:: :: Proposed Mail Protocol + 516:: :: Lost message detection + 512:: :: More on lost message detection + 510:: :: Request for network mailbox addresses + 498:: :: On mail service to CCN + 475:: :: FTP and network mail system + 469:: :: Network mail meeting summary + 458:: :: Mail retrieval via FTP + 453:: :: Meeting announcement to discuss a network mail system + 333:: :: Proposed experiment with a Message Switching Protocol + 278:: :: Revision of theMail Box Protocol + 224:: :: Comments on Mailbox Protocol + 221:: :: Mail Box Protocol + 196:: :: Mail Box Protocol + 58:: :: Logical message synchronization + 42:: :: Message data types +===================================================================== + +NTP +2030:: I:: "Simple Network Time Protocol (SNTP) Version 4 for IPv4, + IPv6 and OSI" +1769:: I:: Simple Network Time Protocol (SNTP) +1708:: I:: NTP PICS PROFORMA For the Network Time Protocol Version 3 +1589:: I:: A Kernel Model for Precision Timekeeping +1361:: I:: Simple Network Time Protocol (SNTP) +1305:: PS:: Network Time Protocol (v3) +1165:: E:: Network Time Protocol (NTP) over the OSI Remote Operations + Service +1129:: :: Internet time synchronization +1128:: :: Measured performance of the Network Time Protocol in the + Internet system +1119:: S:: Network Time Protocol version 2 specification and + implementation +1059:: :: Network Time Protocol version 1 specification and + implementation + 958:: :: Network Time Protocol NTP + 957:: :: Experiments in network clock synchronization + 956:: :: Algorithms for synchronizing network clocks + 868:: S:: Time Protocol + 867:: S:: Daytime Protocol + 778:: H:: DCNET Internet Clock Service + 738:: :: Time server + 29:: :: Response to RFC 28 + 28:: :: Time standards +===================================================================== +Name Serving +2053:: I:: The AM (Armenia) Domain +2052:: E:: A DNS RR for specifying the location of services (DNS SRV) +2010:: I:: Operational Criteria for Root Name Servers +1996:: PS:: A Mechanism for Prompt Notification of Zone Changes + (DNS NOTIFY) +1995:: PS:: Incremental Zone Transfer in DNS +1982:: PS:: Serial Number Arithmetic +1956:: I:: Registration in the MIL Domain +1912:: I:: Common DNS Operational and Configuration Errors +1886:: PS:: DNS Extensions to support IP version 6 +1876:: E:: A Means for Expressing Location Information in the + Domain Name System +1794:: I:: DNS Support for Load Balancing +1713:: I:: Tools for DNS debugging +1712:: E:: DNS Encoding of Geographical Location +1706:: I:: DNS NSAP Resource Records +1664:: E:: Using the Internet DNS to Distribute RFC1327 Mail + Address Mapping Tables +1591:: I:: Domain Name System Structure and Delegation +1537:: I:: Common DNS Data File Configuration Error +1536:: I:: Common DNS Implementation Errors and Suggested Fixes. +1480:: I:: The US Domain +1464:: E:: Using the Domain Name System To Store Arbitrary + String Attributes +1394:: I:: Relationship of Telex Answerback Codes to Internet Domains +1386:: I:: The US Domain +1348:: E:: DNS NSAP RRs +1183:: E:: New DNS RR Definitions +1101:: :: DNS encoding of network names and other types +1035:: S:: Domain names - implementation and specification +1034:: S:: Domain names - concepts and facilities +1033:: :: Domain administrators operations guide +1032:: :: Domain administrators guide +1031:: :: MILNET name domain transition + 973:: :: Domain system changes and observations + 952:: :: DoD Internet host table specification + 921:: :: Domain name system implementation schedule - revised + 920:: :: Domain requirements + 897:: :: Domain name system implementation schedule + 883:: :: Domain names + 882:: :: Domain names + 881:: :: Domain names plan and schedule + 849:: :: Suggestions for improved host table distribution + 830:: :: Distributed system for Internet name service + 819:: :: Domain naming convention for Internet user applications + 811:: :: Hostnames Server + 810:: :: DoD Internet host table specification + 799:: :: Internet name domains + 796:: :: Address mappings + 627:: :: ASCII text file of hostnames + 625:: :: On-line hostnames service + 623:: :: Comments on on-line host name service + 620:: :: Request for monitor host table updates + 608:: :: Host names on-line + 606:: :: Host names on-line + 289:: :: What we hope is an official list of host names + 280:: :: Draft of host names + 273:: :: More on standard host names + 247:: :: Proffered set of standard host names + 237:: :: NIC view of standard host names + 236:: :: Standard host names + 233:: :: Standardization of host call letters + 229:: :: Standard host names + 226:: :: Standardization of host mnemonics +===================================================================== +Network Management +2128:: PS:: Dial Control Management Information Base using SMIv2 +2127:: PS:: ISDN Management Information Base +2124:: I:: Light-weight Flow Admission Protocol Specification + Version 1.0 +2108:: PS:: Definitions of Managed Objects for IEEE 802.3 Repeater + Devices using SMIv2 +2096:: PS:: IP Forwarding Table MIB +2089:: I:: V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual + SNMP agent +2074:: PS:: Remote Network Monitoring MIB Protocol Identifiers +2064:: E:: Traffic Flow Measurement +2063:: E:: Traffic Flow Measurement +2051:: PS:: Definitions of Managed Objects for APPC +2041:: I:: Mobile Network Tracing +2039:: I:: Applicability of Standards Track MIBs to Management + of World Wide Web Servers +2037:: PS:: Entity MIB +2024:: PS:: Definitions of Managed Objects for Data Link Switching + using SNMPv2 +2021:: PS:: Remote Network Monitoring Management Information + Base Version 2 using SMIv2 +2020:: PS:: Definitions of Managed Objects for IEEE 802.12 Interfaces +2013:: PS:: SNMPv2 Management Information Base for the User + Datagram Protocol using SMIv2 +2012:: PS:: SNMPv2 Management Information Base for the + Transmission Control Protocol +2011:: PS:: SNMPv2 Management Information Base for the Internet + Protocol using SMIv2 +2006:: PS:: The Definitions of Managed Objects for IP Mobility + Support using SMIv2 +1944:: I:: Benchmarking Methodology for Network Interconnect Devices +1910:: E:: User-based Security Model for SNMPv2 +1909:: E:: An Administrative Infrastructure for SNMPv2 +1908:: DS:: Coexistence between Version 1 and Version 2 of the + Internet-standard Network Management Framework +1907:: DS:: Management Information Base for Version 2 of the + Simple Network Management Protocol (SNMPv2) +1906:: DS:: Transport Mappings for Version 2 of the Simple Network + Management Protocol (SNMPv2) +1905:: DS:: Protocol Operations for Version 2 of the Simple Network + Management Protocol (SNMPv2) +1904:: DS:: Conformance Statements for Version 2 of the Simple + Network Management Protocol (SNMPv2) +1903:: DS:: Textual Conventions for Version 2 of the Simple + Network Management Protocol (SNMPv2) +1902:: DS:: Structure of Management Information for Version 2 of + the Simple Network Management Protocol (SNMPv2) +1901:: E:: Introduction to Community-based SNMPv2 +1857:: I:: A Model for Common Operational Statistics +1856:: I:: The Opstat Client-Server Model for Statistics Retrieval +1850:: DS:: OSPF Version 2 Management Information Base +1792:: E:: TCP/IPX Connection Mib Specification +1759:: PS:: Printer MIB +1757:: DS:: Remote Network Monitoring Management Information Base +1749:: PS:: IEEE 802.5 Station Source Routing MIB using SMIv2 +1748:: DS:: IEEE 802.5 MIB using SMIv2 +1747:: PS:: Definitions of Managed Objects for SNA Data Link Control +1743:: DS:: IEEE 802.5 MIB using SMIv2 +1742:: PS:: AppleTalk Management Information Base II +1724:: DS:: RIP Version 2 MIB Extension +1697:: PS:: Relational Database Management System (RDBMS) + Management Information Base (MIB) using SMIv2 +1696:: PS:: Modem Management Information Base (MIB) using SMIv2 +1695:: PS:: Definitions of Managed Objects for ATM Management + Version 8.0 using SMIv2 +1694:: DS:: Definitions of Managed Objects for SMDS Interfaces + using SMIv2 +1666:: PS:: Definitions of Managed Objects for SNA NAUs using SMIv2 +1665:: PS:: Definitions of Managed Objects for SNA NAUs using SMIv2 +1660:: DS:: Definitions of Managed Objects for Parallel-printer-like + Hardware Devices using SMIv2 +1659:: DS:: Definitions of Managed Objects for RS-232-like + Hardware Devices using SMIv2 +1658:: DS:: Definitions of Managed Objects for Character Stream + Devices using SMIv2 +1657:: PS:: Definitions of Managed Objects for the Fourth Version + of the Border Gateway Protocol (BGP-4) using SMIv2 +1650:: PS:: Definitions of Managed Objects for the Ethernet-like + Interface Types using SMIv2 +1643:: PS:: Definitions of Managed Objects for the Ethernet-like + Interface Types +1628:: PS:: UPS Management Information Base +1623:: S:: Definitions of Managed Objects for the Ethernet-like + Interface Types +1612:: PS:: DNS Resolver MIB Extensions +1611:: PS:: DNS Server MIB Extensions +1596:: PS:: Definitions of Managed Objects for Frame Relay Service +1595:: PS:: Definitions of Managed Objects for the SONET/SDH + Interface Type +1593:: I:: SNA APPN Node MIB +1592:: E:: Simple Network Management Protocol Distributed Protocol + Interface Version 2.0 +1573:: PS:: Evolution of the Interfaces Group of MIB-II +1567:: PS:: X.500 Directory Monitoring MIB +1566:: PS:: Mail Monitoring MIB +1565:: PS:: Network Services Monitoring MIB +1564:: I:: DSA Metrics (OSI-DS 34 (v3)) +1559:: DS:: DECnet Phase IV MIB Extensions +1525:: PS:: Definitions of Managed Objects for Source Routing Bridges +1516:: DS:: Definitions of Managed Objects for IEEE 802.3 + Repeater Devices +1515:: PS:: Definitions of Managed Objects for IEEE 802.3 + Medium Attachment Units (MAUs) +1514:: PS:: Host Resources MIB +1513:: PS:: Token Ring Extensions to the Remote Network Monitoring MIB +1512:: PS:: FDDI Management Information Base +1503:: I:: Algorithms for Automating Administration in SNMPv2 + Managers +1493:: DS:: Definitions of Managed Objects for Bridges +1474:: PS:: The Definitions of Managed Objects for the Bridge + Network Control Protocol of the Point-to-Point Protocol +1473:: PS:: The Definitions of Managed Objects for the IP Network + Control Protocol of the Point-to-Point Protocol +1472:: PS:: The Definitions of Managed Objects for the Security + Protocols of the Point-to-Point Protocol +1471:: PS:: The Definitions of Managed Objects for the Link Control + Protocol of the Point-to-Point Protocol +1470:: I:: FYI on a Network Management Tool Catalog +1461:: PS:: SNMP MIB extension for MultiProtocol Interconnect over + X.25 +1452:: PS:: Coexistence between version 1 and version 2 of the + Internet-standard Network Management Framework +1451:: PS:: Manager to Manager Management Information Base +1450:: PS:: Management Information Base for version 2 of the Simple + Network Management Protocol (SNMPv2) +1449:: PS:: Transport Mappings for version 2 of the Simple Network + Management Protocol (SNMPv2) +1448:: PS:: Protocol Operations for version 2 of the Simple Network + Management Protocol (SNMPv2) +1447:: PS:: Party MIB for version 2 of the Simple Network Management + Protocol (SNMPv2) +1446:: PS:: Security Protocols for version 2 of the Simple Network + Management Protocol (SNMPv2) +1445:: PS:: Administrative Model for version 2 of the Simple Network + Management Protocol (SNMPv2) +1444:: PS:: Conformance Statements for version 2 of the Simple + Network Management Protocol (SNMPv2) +1443:: PS:: Textual Conventions for version 2 of the Simple Network + Management Protocol (SNMPv2) +1442:: PS:: Structure of Management Information for version 2 of the + Simple Network Management Protocol (SNMPv2) +1441:: PS:: Introduction to version 2 of the Internet-standard + Network Management Framework +1431:: I:: DUA Metrics +1420:: PS:: SNMP over IPX +1419:: PS:: SNMP over AppleTalk +1418:: PS:: SNMP over OSI +1414:: PS:: Ident MIB +1407:: PS:: Definitions of Managed Objects for the DS3/E3 Interface + Type +1406:: PS:: Definitions of Managed Objects for the DS1 and E1 + Interface Types +1404:: I:: A Model for Common Operational Statistics +1398:: DS:: Definitions of Managed Objects for the Ethernet-like + Interface Types +1389:: PS:: RIP Version 2 MIB Extension +1382:: PS:: SNMP MIB Extension for the X.25 Packet Layer +1381:: PS:: SNMP MIB Extension for X.25 LAPB +1369:: I:: Implementation Notes and Experience for The Internet + Ethernet MIB +1368:: PS:: Definitions of Managed Objects for IEEE 802.3 Repeater + Devices +1354:: PS:: IP Forwarding Table MIB +1353:: H:: Definitions of Managed Objects for Administration of + SNMP Parties +1352:: H:: SNMP Security Protocols +1351:: H:: SNMP Administrative Model +1346:: I:: "Resource Allocation, Control, and Accounting for the + Use of Network Resources" +1318:: PS:: Definitions of Managed Objects for Parallel-printer-like + Hardware Devices +1317:: PS:: Definitions of Managed Objects for RS-232-like + Hardware Devices +1316:: PS:: Definitions of Managed Objects for Character Stream + Devices +1315:: PS:: Management Information Base for Frame Relay DTEs +1304:: PS:: Definitions of Managed Objects for the SIP Interface Type +1303:: I:: A Convention for Describing SNMP-based Agents +1298:: I:: SNMP over IPX +1289:: PS:: DECnet Phase IV MIB Extensions +1286:: PS:: Definitions of Managed Objects for Bridges +1285:: PS:: FDDI Management Information Base +1284:: PS:: Definitions of Managed Objects for the Ethernet-like + Interface Types +1283:: E:: SNMP over OSI +1273:: I:: "A Measurement Study of Changes in Service-Level + Reachability in the Global TCP/IP Internet +1272:: I:: Internet Accounting +1271:: PS:: Remote Network Monitoring Management Information Base +1270:: I:: SNMP Communications Services +1269:: PS:: Definitions of Managed Objects for the Border Gateway + Protocol (Version 3) +1262:: :: Guidelines for Internet Measurement Activities +1253:: PS:: OSPF Version 2 Management Information Base +1252:: PS:: OSPF Version 2 Management Information Base +1248:: PS:: OSPF Version 2 Management Information Base +1247:: DS:: OSPF Version 2 +1243:: PS:: AppleTalk Management Information Base +1242:: I:: Benchmarking Terminology for Network Interconnection + Devices +1239:: PS:: Reassignment of Experimental MIBs to Standard MIBs +1238:: E:: CLNS MIB - for use with Connectionless Network + Protocol (ISO 8473) and End System to Intermediate + System (ISO 9542) +1233:: H:: Definitions of Managed Objects for the DS3 Interface Type +1232:: H:: Definitions of Managed Objects for the DS1 Interface Type +1231:: DS:: IEEE 802.5 Token Ring MIB +1230:: H:: IEEE 802.4 Token Bus MIB +1229:: DS:: Extensions to the Generic-Interface MIB +1228:: E:: SNMP-DPI - Simple Network Management Protocol + Distributed Program Interface +1227:: E:: SNMP MUX Protocol and MIB +1224:: E:: Techniques for Managing Asynchronously Generated Alerts +1215:: I:: A Convention for Defining Traps for use with the SNMP +1214:: H:: OSI Internet Management +1213:: S:: Management Information Base for Network Management of + TCP/IP-based internets +1212:: S:: Concise MIB Definitions +1189:: H:: The Common Management Information Services and Protocols + for the Internet +1187:: E:: Bulk Table Retrieval with the SNMP +1161:: E:: SNMP over OSI +1158:: PS:: Management Information Base for Network Management of +TCP/IP-based internets +1157:: S:: A Simple Network Management Protocol (SNMP) +1155:: S:: Structure and Identification of Management Information + for TCP/IP-based Internets +1109:: :: Report of the second Ad Hoc Network Management Review + Group +1098:: :: Simple Network Management Protocol SNMP +1095:: DS:: Common Management Information Services and Protocol + over TCP/IP CMOT +1089:: :: SNMP over Ethernet +1067:: :: Simple Network Management Protocol +1066:: H:: Management Information Base for network management of + TCP/IP-based internets +1065:: H:: Structure and identification of management information + for TCP/IP-based internets +1052:: :: IAB recommendations for the development of Internet + network management standards +1028:: H:: Simple Gateway Monitoring Protocol +1024:: :: HEMS variable definitions +1023:: :: HEMS monitoring and control language +1022:: :: High-level Entity Management Protocol HEMP +1021:: H:: High-level Entity Management System HEMS +1012:: :: Bibliography of Request For Comments 1 through 999 +1011:: S:: Official Internet protocols +1010:: S:: Assigned numbers + 996:: H:: Statistics server + 619:: :: Mean round-trip times in the ARPANET + 618:: :: Few observations on NCP statistics + 616:: :: Latest network maps + 615:: :: Proposed Network Standard Data Pathname Syntax + 612:: :: Traffic statistics December 1973 + 601:: :: Traffic statistics November 1973 + 586:: :: Traffic statistics October 1973 + 579:: :: Traffic statistics September 1973 + 568:: :: Response to RFC 567 - cross country network bandwidth + 567:: :: Cross country network bandwidth + 566:: :: Traffic statistics August 1973 + 565:: :: Storing network survey data at the datacomputer + 557:: :: Revelations in network host measurements + 546:: :: Tenex load averages for July 1973 + 545:: :: Of what quality be the UCSB resources evaluators? + 538:: :: Traffic statistics June 1973 + 531:: :: Feast or famine? A response to two recent RFC's about + network information + 522:: :: Traffic statistics May 1973 + 509:: :: Traffic statistics April 1973 + 500:: :: Integration of data management systems on a computer + network + 482:: :: Traffic statistics February 1973 + 455:: :: Traffic statistics January 1973 + 443:: :: Traffic statistics December 1972 + 423:: :: UCLA Campus Computing Network liaison staff for ARPANET + 422:: :: Traffic statistics November 1972 + 421:: :: Software consulting service for network users + 416:: :: ARC system will be unavailable for use during + Thanksgivingweek  + 415:: :: Tenex bandwidth + 413:: :: Traffic statistics October 1972 + 400:: :: Traffic statistics September 1972 + 392:: :: Measurement of host costs for transmitting network data + 391:: :: Traffic statistics August 1972 + 389:: :: UCLA Campus Computing Network liaison staff for ARPA + Network + 388:: :: NCP statistics + 384:: :: Official site idents for organizations in the ARPA + Network + 381:: :: Three aids to improved network operation + 378:: :: Traffic statistics July 1972 + 369:: :: "Evaluation of ARPANET services January-March, 1972" + 362:: :: Network host status + 353:: :: Network host status + 344:: :: Network host status + 326:: :: Network host status + 323:: :: Formation of Network Measurement Group NMG + 308:: :: ARPANET host availability data + 304:: :: Data management system proposal for the ARPA network + 302:: :: Exercising the ARPANET + 274:: :: Establishing a local guide for network usage + 227:: :: Data transfer rates Rand/UCLA + 212:: :: NWG meeting on network usage + 193:: :: Network checkout + 188:: :: Data management meeting announcement + 156:: :: Status of the Illinois site + 153:: :: SRI ARC-NIC status + 96:: :: Interactive network experiment to study modes of + access tothe Network Information Center + 32:: :: Connecting M.I.T. computers to the + ARPA Computer-to-computer communication network + 18:: :: [Link assignments] + ====================================================================== +Network News + +1036:: :: Standard for interchange of USENET messages + 977:: PS:: Network News Transfer Protocol + 850:: :: Standard for interchange of USENET messages +=================================================================== +Real Time Services +:: :: +2102:: I:: Multicast Support for Nimrod +2090:: E:: TFTP Multicast Option +2038:: PS:: RTP Payload Format for MPEG1/MPEG2 Video +2035:: PS:: RTP Payload Format for JPEG-compressed Video +2032:: PS:: RTP payload format for H.261 video streams +2029:: PS:: RTP Payload Format of Sun's CellB Video Encoding +2022:: PS:: Support for Multicast over UNI 3.0/3.1 based ATM + Networks +1890:: PS:: RTP Profile for Audio and Video Conferences with Minimal + Control +1889:: PS:: RTP +1861:: I:: Simple Network Paging Protocol - Version 3 - Two-Way + Enhanced +1821:: I:: Integration of Real-time Services in an IP-ATM Network + Architecture +1819:: E:: Internet Stream Protocol Version 2 (ST2) Protocol + Specification - Version ST2+ +1789:: I:: INETPhone +1768:: E:: Host Group Extensions for CLNP Multicasting +1703:: I:: Principles of Operation for the TPC.INT Subdomain +1645:: I:: Simple Network Paging Protocol - Version 2 +1614:: I:: Network Access to Multimedia Information +1569:: I:: Principles of Operation for the TPC.INT Subdomain +1568:: I:: Simple Network Paging Protocol - Version 1(b) +1546:: I:: Host Anycasting Service +1469:: PS:: IP Multicast over Token-Ring Local Area Networks +1458:: I:: Requirements for Multicast Protocols +1453:: I:: A Comment on Packet Video Remote Conferencing and the + Transport/Network Layers +1313:: I:: Today's Programming for KRFC AM 1313 Internet Talk Radio +1301:: I:: Multicast Transport Protocol +1257:: I:: Isochronous Applications Do Not Require + Jitter-Controlled Networks +1197:: I:: Using ODA for Translating Multimedia Information +1193:: :: Client Requirements for Real-Time Communication Services +1190:: E:: "Experimental Internet Stream Protocol, Version 2 (ST-II)" +1112:: S:: Host extensions for IP multicasting +1054:: :: Host extensions for IP multicasting + 988:: :: Host extensions for IP multicasting + 966:: :: Host groups + 947:: :: Multi-network broadcasting within the Internet + 809:: :: UCL facsimile system + 804:: :: CCITT draft recommendation T.4 [Standardization of + Group 3 facsimile apparatus for document transmission] + 803:: :: Dacom 450/500 facsimile data transcoding + 798:: :: Decoding facsimile data from the Rapicom 450 + 769:: :: Rapicom 450 facsimile file format + 741:: :: Specifications for the Network Voice Protocol NVP + 511:: :: Enterprise phone service to NIC from ARPANET sites + 508:: :: Real-time data transmission on the ARPANET + 420:: :: CCA ICCC weather demo + 408:: :: NETBANK + 251:: :: Weather data +===================================================================== +Routing + +2103:: I:: Mobility Support for Nimrod +2092:: I:: Protocol Analysis for Triggered RIP +2091:: PS:: Triggered Extensions to RIP to Support Demand Circuits +2081:: I:: RIPng Protocol Applicability Statement +2080:: PS:: RIPng for IPv6 +2073:: PS:: An IPv6 Provider-Based Unicast Address Format +2072:: I:: Router Renumbering Guide +2042:: I:: Registering New BGP Attribute Types +2008:: BC:: Implications of Various Address Allocation Policies for + Internet Routing +1998:: I:: An Application of the BGP Community Attribute in + Multi-home Routing +1997:: PS:: BGP Communities Attribute +1992:: I:: The Nimrod Routing Architecture +1987:: I:: Ipsilon's General Switch Management Protocol + Specification Version 1.1 +1966:: E:: BGP Route Reflection An alternative to full mesh IBGP +1965:: E:: Autonomous System Confederations for BGP +1955:: I:: New Scheme for Internet Routing and Addressing (ENCAPS) + for IPN +1953:: I:: Ipsilon Flow Management Protocol Specification for + IPv4 Version 1.0 +1940:: I:: Source Demand Routing +1930:: BC:: "Guidelines for creation, selection, and registration + of an Autonomous System (AS)" +1925:: I:: The Twelve Networking Truths +1923:: I:: RIPv1 Applicability Statement for Historic Status +1863:: E:: A BGP/IDRP Route Server alternative to a full mesh routing +1817:: I:: CIDR and Classful Routing +1812:: PS:: Requirements for IP Version 4 Routers +1793:: PS:: Extending OSPF to Support Demand Circuits +1787:: I:: Routing in a Multi-provider Internet +1786:: I:: Representation of IP Routing Policies in a Routing Registry (ripe-81++) +1774:: I:: BGP-4 Protocol Analysis +1773:: I:: Experience with the BGP-4 protocol +1772:: DS:: Application of the Border Gateway Protocol in the Internet +1771:: DS:: A Border Gateway Protocol 4 (BGP-4) +1765:: E:: OSPF Database Overflow +1753:: I:: IPng Technical Requirements Of the Nimrod Routing and + Addressing Architecture +1745:: PS:: BGP4/IDRP for IP---OSPF Interaction +1723:: DS:: RIP Version 2 Carrying Additional Information +1722:: DS:: RIP Version 2 Protocol Applicability Statement +1721:: I:: RIP Version 2 Protocol Analysis +1716:: I:: Towards Requirements for IP Routers +1702:: I:: Generic Routing Encapsulation over IPv4 networks +1701:: I:: Generic Routing Encapsulation (GRE) +1668:: I:: Unified Routing Requirements for IPng +1656:: I:: BGP-4 Protocol Document Roadmap and Implementation + Experience +1655:: PS:: Application of the Border Gateway Protocol in the + Internet +1654:: PS:: A Border Gateway Protocol 4 (BGP-4) +1587:: PS:: The OSPF NSSA Option +1586:: I:: Guidelines for Running OSPF Over Frame Relay Networks +1585:: I:: MOSPF +1584:: PS:: Multicast Extensions to OSPF +1583:: DS:: OSPF Version 2 +1582:: PS:: Extensions to RIP to Support Demand Circuits +1581:: I:: Protocol Analysis for Extensions to RIP to Support + Demand Circuits +1520:: I:: Exchanging Routing Information Across Provider Boundaries + in the CIDR Environment +1519:: PS:: Classless Inter-Domain Routing (CIDR) +1517:: PS:: Applicability Statement for the Implementation of + Classless Inter-Domain Routing (CIDR) +1504:: I:: Appletalk Update-Based Routing Protocol +1482:: I:: Aggregation Support in the NSFNET Policy Routing Database +1479:: PS:: Inter-Domain Policy Routing Protocol Specification +1478:: PS:: An Architecture for Inter-Domain Policy Routing +1477:: I:: IDPR as a Proposed Standard +1476:: E:: RAP +1439:: I:: The Uniqueness of Unique Identifiers +1403:: PS:: BGP OSPF Interaction +1397:: PS:: Default Route Advertisement In BGP2 And BGP3 Versions Of + The Border Gateway Protocol +1388:: PS:: RIP Version 2 Carrying Additional Information +1387:: I:: RIP Version 2 Protocol Analysis +1383:: I:: An Experiment in DNS Based IP Routing +1380:: I:: IESG Deliberations on Routing and Addressing +1371:: I:: "Choosing a ""Common IGP"" for the IP Internet (The + IESG's Recommendation to the IAB)" +1370:: PS:: Applicability Statement for OSPF +1364:: PS:: BGP OSPF Interaction +1338:: I:: Supernetting +1322:: I:: A Unified Approach to Inter-Domain Routing +1268:: DS:: Application of the Border Gateway Protocol in the Internet +1267:: DS:: A Border Gateway Protocol 3 (BGP-3) +1266:: I:: Experience with the BGP Protocol +1265:: I:: BGP Protocol Analysis +1264:: I:: Internet Routing Protocol Standardization Criteria +1254:: I:: Gateway Congestion Control Survey +1246:: I:: Experience with the OSPF Protocol +1245:: I:: OSPF Protocol Analysis +1222:: :: Advancing the NSFNET Routing Architecture +1195:: PS:: Use of OSI IS-IS for Routing in TCP/IP and Dual + Environments +1164:: PS:: Application of the Border Gateway Protocol in the Internet +1163:: PS:: A Border Gateway Protocol (BGP) +1142:: I:: OSI IS-IS Intra-domain Routing Protocol +1136:: :: Administrative Domains and Routing Domains +1133:: :: Routing between the NSFNET and the DDN +1131:: PS:: OSPF specification +1126:: :: Goals and functional requirements for inter-autonomous + system routing +1125:: :: Policy requirements for inter Administrative Domain + routing +1124:: :: Policy issues in interconnecting networks +1105:: E:: Border Gateway Protocol BGP +1104:: :: Models of policy based routing +1102:: :: Policy routing in Internet protocols +1092:: :: EGP and policy based routing in the new NSFNET backbone +1075:: E:: Distance Vector Multicast Routing Protocol +1074:: :: NSFNET backbone SPF based Interior Gateway Protocol +1058:: S:: Routing Information Protocol +1009:: H:: Requirements for Internet gateways + 995:: :: End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473 + 985:: :: Requirements for Internet gateways - draft + 981:: :: Experimental multiple-path routing algorithm + 975:: :: Autonomous confederations + 950:: S:: Internet standard subnetting procedure + 911:: :: EGP Gateway under Berkeley UNIX 4.2 + 904:: H:: Exterior Gateway Protocol formal specification + 898:: :: Gateway special interest group meeting notes + 890:: :: Exterior Gateway Protocol implementation schedule + 888:: :: STUB Exterior Gateway Protocol + 875:: :: "Gateways, architectures, and heffalumps" + 827:: :: Exterior Gateway Protocol EGP + 823:: H:: DARPA Internet gateway +===================================================================== + +Security + +2104:: I:: HMAC +2085:: PS:: HMAC-MD5 IP Authentication with Replay Prevention +2084:: I:: Considerations for Web Transaction Security +2082:: PS:: RIP-2 MD5 Authentication +2078:: PS:: "Generic Security Service Application Program Interface, + Version 2" +2069:: PS:: An Extension to HTTP +2065:: PS:: Domain Name System Security Extensions +2059:: I:: RADIUS Accounting +2058:: PS:: Remote Authentication Dial In User Service (RADIUS) +2057:: I:: Source directed access control on the Internet. +2040:: I:: "The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms" +2025:: PS:: The Simple Public-Key GSS-API Mechanism (SPKM) +2015:: :: MIME Security with Pretty Good Privacy (PGP) +1984:: I:: IAB and IESG Statement on Cryptographic Technology and + the Internet +1969:: I:: The PPP DES Encryption Protocol (DESE) +1968:: PS:: The PPP Encryption Control Protocol (ECP) +1964:: PS:: The Kerberos Version 5 GSS-API Mechanism +1961:: PS:: GSS-API Authentication Method for SOCKS Version 5 +1949:: E:: Scalable Multicast Key Distribution +1948:: I:: Defending Against Sequence Number Attacks +1938:: PS:: A One-Time Password System +1929:: PS:: Username/Password Authentication for SOCKS V5 +1928:: PS:: SOCKS Protocol Version 5 +1898:: I:: CyberCash Credit Card Protocol Version 0.8 +1858:: I:: Security Considerations for IP Fragment Filtering +1852:: E:: IP Authentication using Keyed SHA +1851:: E:: The ESP Triple DES-CBC Transform +1829:: PS:: The ESP DES-CBC Transform +1828:: PS:: IP Authentication using Keyed MD5 +1827:: PS:: IP Encapsulating Security Payload (ESP) +1826:: PS:: IP Authentication Header +1825:: PS:: Security Architecture for the Internet Protocol +1824:: I:: The Exponential Security System TESS +1760:: I:: The S/KEY One-Time Password System +1751:: I:: A Convention for Human-Readable 128-bit Keys +1750:: I:: Randomness Recommendations for Security +1704:: I:: On Internet Authentication +1675:: I:: Security Concerns for IPng +1579:: I:: Firewall-Friendly FTP +1535:: I:: A Security Problem and Proposed Correction With Widely + Deployed DNS Software +1511:: I:: Common Authentication Technology Overview +1510:: PS:: The Kerberos Network Authentication Service (V5) +1509:: PS:: Generic Security Service API +1508:: PS:: Generic Security Service Application Program Interface +1507:: E:: DASS - Distributed Authentication Security Service +1492:: I:: "An Access Control Protocol, Sometimes Called TACACS" +1457:: I:: Security Label Framework for the Internet +1455:: E:: Physical Link Security Type of Service +1424:: PS:: Privacy Enhancement for Internet Electronic Mail +1423:: PS:: "Privacy Enhancement for Internet Electronic Mail +1422:: PS:: Privacy Enhancement for Internet Electronic Mail +1421:: PS:: Privacy Enhancement for Internet Electronic Mail +1416:: E:: Telnet Authentication Option +1412:: E:: Telnet Authentication +1411:: E:: Telnet Authentication +1409:: E:: Telnet Authentication Option +1408:: H:: Telnet Environment Option +1321:: I:: The MD5 Message-Digest Algorithm +1320:: I:: The MD4 Message-Digest Algorithm +1319:: I:: The MD2 Message-Digest Algorithm +1281:: I:: Guidelines for the Secure Operation of the Internet +1244:: I:: Site Security Handbook +1186:: I:: The MD4 Message Digest Algorithm +1170:: I:: Public Key Standards and Licenses +1156:: S:: Management Information Base for Network Management of + TCP/IP-based internets +1115:: H:: "Privacy enhancement for Internet electronic mail +1114:: H:: Privacy enhancement for Internet electronic mail +1113:: H:: Privacy enhancement for Internet electronic mail +1108:: PS:: U.S. Department of Defense Security Options for the + Internet Protocol +1040:: :: Privacy enhancement for Internet electronic mail +1038:: :: Draft revised IP security option +1004:: E:: Distributed-protocol authentication scheme + 989:: :: Privacy enhancement for Internet electronic mail + 972:: :: Password Generator Protocol + 931:: E:: Authentication server + 927:: :: TACACS user identification Telnet option + 912:: :: Authentication service + 644:: :: On the problem of signature authentication for + network mail +===================================================================== +Virtual Terminal + +2066:: E:: TELNET CHARSET Option +1647:: PS:: TN3270 Enhancements +1646:: I:: TN3270 Extensions for LUname and Printer Selection +1576:: I:: TN3270 Current Practices +1572:: PS:: Telnet Environment Option +1571:: I:: Telnet Environment Option Interoperability Issues +1372:: PS:: Telnet Remote Flow Control Option +1282:: I:: BSD Rlogin +1258:: I:: BSD Rlogin +1221:: :: Host Access Protocol (HAP) Specification - Version 2 +1205:: :: 5250 Telnet Interface +1184:: DS:: Telnet Linemode Option +1143:: :: The Q Method of Implementing TELNET Option Negotiation +1116:: PS:: Telnet Linemode option +1097:: :: Telnet subliminal-message option +1096:: :: Telnet X display location option +1091:: :: Telnet terminal-type option +1080:: :: Telnet remote flow control option +1079:: :: Telnet terminal speed option +1073:: :: Telnet window size option +1053:: :: Telnet X.3 PAD option +1043:: :: Telnet Data Entry Terminal option +1041:: :: Telnet 3270 regime option +1013:: :: "X Window System Protocol, version 11 +1005:: :: ARPANET AHIP-E Host Access Protocol enhanced AHIP + 946:: :: Telnet terminal location number option + 933:: :: Output marking Telnet option + 930:: :: Telnet terminal type option + 929:: :: Proposed Host-Front End Protocol + 907:: S:: Host Access Protocol specification + 885:: :: Telnet end of record option + 884:: :: Telnet terminal type option + 878:: :: ARPANET 1822L Host Access Protocol + 861:: :: Telnet extended options + 860:: S:: Telnet timing mark option + 859:: S:: Telnet status option + 858:: S:: Telnet Suppress Go Ahead option + 857:: S:: Telnet echo option + 856:: S:: Telnet binary transmission + 855:: S:: Telnet option specifications + 854:: S:: Telnet Protocol specification + 851:: :: ARPANET 1822L Host Access Protocol + 818:: H:: Remote User Telnet service + 802:: :: ARPANET 1822L Host Access Protocol + 782:: :: Virtual Terminal management model + 779:: :: Telnet send-location option + 764:: :: Telnet Protocol specification + 749:: :: Telnet SUPDUP-Output option + 748:: :: Telnet randomly-lose option + 747:: :: Recent extensions to the SUPDUP Protocol + 746:: :: SUPDUP graphics extension + 736:: :: Telnet SUPDUP option + 735:: :: Revised Telnet byte macro option + 734:: H:: SUPDUP Protocol + 732:: :: Telnet Data Entry Terminal option + 731:: :: Telnet Data Entry Terminal option + 729:: :: Telnet byte macro option + 728:: :: Minor pitfall in the Telnet Protocol + 727:: :: Telnet logout option + 726:: :: Remote Controlled Transmission and Echoing Telnet option + 721:: :: Out-of-band control signals in a Host-to-Host Protocol + 719:: :: Discussion on RCTE + 718:: :: Comments on RCTE from the Tenex implementation experience + 703:: :: "July, 1975, survey of New-Protocol Telnet Servers" + 702:: :: "September, 1974, survey of New-Protocol Telnet servers" + 701:: :: "August, 1974, survey of New-Protocol Telnet servers" + 698:: :: Telnet extended ASCII option + 688:: :: Tentative schedule for the new Telnet implementation for + the TIP + 679:: :: "February, 1975, survey of New-Protocol Telnet servers" + 669:: :: "November, 1974, survey of New-Protocol Telnet servers" + 659:: :: Announcing additional Telnet options + 658:: :: Telnet output linefeed disposition + 657:: :: Telnet output vertical tab disposition option + 656:: :: Telnet output vertical tabstops option + 655:: :: Telnet output formfeed disposition option + 654:: :: Telnet output horizontal tab disposition option + 653:: :: Telnet output horizontal tabstops option + 652:: :: Telnet output carriage-return disposition option + 651:: :: Revised Telnet status option + 647:: :: Proposed protocol for connecting host computers to + ARPA-like networks via front end processors + 636:: :: TIP/Tenex reliability improvements + 600:: :: Interfacing an Illinois plasma terminal to the ARPANET + 596:: :: Second thoughts on Telnet Go-Ahead + 595:: :: Second thoughts in defense of the Telnet Go-Ahead + 587:: :: Announcing new Telnet options + 563:: :: Comments on the RCTE Telnet option + 562:: :: Modifications to the Telnet specification + 560:: :: Remote Controlled Transmission and Echoing Telnet option + 559:: :: Comments on the new Telnet Protocol and its implementation + 513:: :: Comments on the new Telnet specifications + 495:: :: Telnet Protocol specifications + 470:: :: Change in socket for TIP news facility + 466:: :: Telnet logger/server for host LL-67 + 461:: :: Telnet Protocol meeting announcement + 447:: :: IMP/TIP memory retrofit schedule + 435:: :: Telnet issues + 431:: :: Update on SMFS login and logout + 399:: :: SMFS login and logout + 393:: :: Comments on Telnet Protocol changes + 386:: :: Letter to TIP users-2 + 377:: :: Using TSO via ARPA Network Virtual Terminal + 365:: :: Letter to all TIP users + 364:: :: Serving remote users on the ARPANET + 352:: :: TIP site information form + 340:: :: Proposed Telnet changes + 339:: :: "MLTNET + 328:: :: Suggested Telnet Protocol changes + 318:: :: [Ad hoc Telnet Protocol] + 311:: :: New console attachments to the USCB host + 297:: :: TIP message buffers + 296:: :: DS-1 display system + 231:: :: Service center standards for remote usage + 230:: :: Toward reliable operation of minicomputer-based + terminals on a TIP + 216:: :: Telnet access to UCSB's On-Line System + 215:: :: "NCP, ICP, and Telnet + 206:: :: User Telnet - description of an initial implementation + 205:: :: NETCRT - a character display protocol + 177:: :: Device independent graphical display description + 158:: :: Telnet Protocol + 139:: :: Discussion of Telnet Protocol + 137:: :: Telnet Protocol - a proposed document + 110:: :: Conventions for using an IBM 2741 terminal as a + user console for access to network server hosts + 97:: :: First cut at a proposed Telnet Protocol +===================================================================== +Other + +2123:: I:: Traffic Flow Measurement +2121:: I:: Issues affecting MARS Cluster Size +2119:: BC:: Key words for use in RFCs to Indicate Requirement Levels +2101:: I:: IPv4 Address Behaviour Today +2100:: I:: The Naming of Hosts +2099:: I:: Request for Comments Summary RFC Numbers 2000-2099 +2083:: I:: PNG (Portable Network Graphics) Specification Version 1.0 +2071:: I:: Network Renumbering Overview +2050:: BC:: INTERNET REGISTRY IP ALLOCATION GUIDELINES +2036:: I:: Observations on the use of Components of the Class + A Address Space within the Internet +2031:: I:: IETF-ISOC relationship +2028:: BC:: The Organizations Involved in the IETF Standards Process +2027:: BC:: "IAB and IESG Selection, Confirmation, and Recall Process +2026:: BC:: The Internet Standards Process -- Revision 3 +2014:: BC:: IRTF Research Group Guidelines and Procedures +2007:: I:: Catalogue of Network Training Materials +2000:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS +1999:: I:: Request for Comments Summary RFC Numbers 1900-1999 +1988:: I:: Conditional Grant of Rights to Specific Hewlett-Packard + Patents In Conjunction With the Internet Engineering + Task Force's Internet-Standard Network Management + Framework +1983:: I:: Internet Users' Glossary +1958:: I:: Architectural Principles of the Internet +1952:: I:: GZIP file format specification version 4.3 +1951:: I:: DEFLATE Compressed Data Format Specification version 1.3 +1950:: I:: ZLIB Compressed Data Format Specification version 3.3 +1941:: I:: Frequently Asked Questions for Schools +1935:: I:: "What is the Internet, Anyway?" +1920:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS +1900:: I:: Renumbering Needs Work +1899:: I:: Request for Comments Summary RFC Numbers 1800-1899 +1882:: I:: The 12-Days of Technology Before Christmas +1880:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS +1879:: I:: Class A Subnet Experiment Results and Recommendations +1875:: I:: UNINETT PCA Policy Statements +1871:: BC:: Addendum to RFC 1602 -- Variance Procedure +1855:: I:: Netiquette Guidelines +1822:: I:: A Grant of Rights to Use a Specific IBM patent with + Photuris +1818:: S:: Best Current Practices +1816:: I:: U.S. Government Internet Domain Names +1814:: I:: Unique Addresses are Good +1811:: I:: U.S. Government Internet Domain Names +1810:: I:: Report on MD5 Performance +1805:: I:: Location-Independent Data/Software Integrity Protocol +1802:: I:: Introducing Project Long Bud +1800:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS +1799:: I:: Request for Comments Summary RFC Numbers 1700-1799 +1797:: E:: Class A Subnet Experiment +1796:: I:: Not All RFCs are Standards +1790:: I:: "An Agreement between the Internet Society and Sun + Microsystems, Inc. in the Matter of ONC RPC and + XDR Protocols" +1780:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS +1776:: I:: The Address is the Message +1775:: I:: "To Be ""On"" the Internet" +1758:: I:: NADF Standing Documents +1746:: I:: Ways to Define User Expectations +1739:: I:: A Primer On Internet and TCP/IP Tools +1720:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS +1718:: I:: The Tao of IETF - A Guide for New Attendees of the + Internet Engineering Task Force +1715:: I:: The H Ratio for Address Assignment Efficiency +1709:: I:: K-12 Internetworking Guidelines +1700:: S:: ASSIGNED NUMBERS +1699:: I:: Request for Comments Summary RFC Numbers 1600-1699 +1691:: I:: The Document Architecture for the Cornell Digital Library +1690:: I:: Introducing the Internet Engineering and Planning + Group (IEPG) +1689:: I:: A Status Report on Networked Information Retrieval +1640:: I:: The Process for Organization of Internet Standards + Working Group (POISED) +1636:: I:: "Report of IAB Workshop on Security in the Internet + Architecture - February 8-10, 1994" +1635:: I:: How to Use Anonymous FTP +1627:: I:: Network 10 Considered Harmful (Some Practices + Shouldn't be Codified) +1610:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS +1607:: I:: A VIEW FROM THE 21ST CENTURY +1606:: I:: A Historical Perspective On The Usage Of IP Version 9 +1603:: I:: IETF Working Group Guidelines and Procedures +1602:: I:: The Internet Standards Process -- Revision 2 +1601:: I:: Charter of the Internet Architecture Board (IAB) +1600:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS +1599:: I:: Request for Comments Summary RFC Numbers 1500 - 1599 +1597:: I:: Address Allocation for Private Internets +1594:: I:: FYI on Questions and Answer Answers to Commonly + asked ``New Internet User'' Questions +1580:: I:: Guide to Network Resource Tools +1578:: I:: FYI on Questions and Answers +1574:: I:: Essential Tools for the OSI Internet +1550:: I:: IP +1543:: I:: Instructions to RFC Authors +1540:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS +1539:: I:: The Tao of IETF - A Guide for New Attendees of the + Internet Engineering Task Force +1527:: I:: What Should We Plan Given the Dilemma of the Network? +1501:: I:: OS/2 User Group +1500:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS +1499:: I:: Request for Comments Summary RFC Numbers 1400-1499 +1481:: I:: IAB Recommendation for an Intermediate Strategy to + Address the Issue of Scaling +1467:: I:: Status of CIDR Deployment in the Internet +1463:: I:: FYI on Introducing the Internet--A Short Bibliography + of Introductory Internetworking Readings for the + Network Novice +1462:: I:: FYI on ``What is the Internet?'' +1438:: I:: Internet Engineering Task Force Statements Of + Boredom (SOBs) +1432:: I:: Recent Internet Books +1417:: I:: NADF Standing Documents +1410:: S:: IAB OFFICIAL PROTOCOL STANDARDS +1402:: I:: There's Gold in them thar Networks! Searching for + Treasure in all the Wrong Places +1401:: I:: Correspondence between the IAB and DISA on the use + of DNS throughout the Internet +1399:: I:: Request for Comments Summary RFC Numbers 1300-1399 +1396:: I:: The Process for Organization of Internet Standards + Working Group (POISED) +1392:: I:: Internet Users' Glossary +1391:: I:: The Tao of IETF +1367:: I:: Schedule for IP Address Space Management Guidelines +1366:: I:: Guidelines for Management of IP Address Space +1360:: S:: IAB OFFICIAL PROTOCOL STANDARDS +1359:: I:: Connecting to the Internet What Connecting + Institutions Should Anticipate +1358:: I:: Charter of the Internet Architecture Board (IAB) +1349:: PS:: Type of Service in the Internet Protocol Suite +1340:: S:: ASSIGNED NUMBERS +1336:: I:: "Who's Who in the Internet Biographies of IAB, + IESG and IRSG Members" +1325:: I:: FYI on Questions and Answers Answers to Commonly + asked ``New Internet User'' Questions +1324:: I:: A Discussion on Computer Network Conferencing +1311:: I:: Introduction to the STD Notes +1310:: I:: The Internet Standards Process +1300:: I:: Remembrances of Things Past +1299:: I:: Request for Comments Summary RFC Numbers 1200-1299 +1297:: I:: NOC Internal Integrated Trouble Ticket System + Functional Specification Wishlist + (``NOC TT REQUIREMENTS'') +1296:: I:: Internet Growth (1981-1991) +1295:: I:: User Bill of Rights for entries and listings in the + Public Directory +1291:: I:: Mid-Level Networks +1290:: I:: There's Gold in them thar Networks! or Searching for + Treasure in all the Wrong Places +1287:: I:: Towards the Future Internet Architecture +1280:: S:: IAB OFFICIAL PROTOCOL STANDARDS +1261:: I:: Transition of NIC Services +1259:: I:: Building The Open Road +1251:: :: "Who's Who in the Internet +1250:: S:: IAB Official Protocol Standards +1249:: I:: DIXIE Protocol Specification +1217:: :: Memo from the Consortium for Slow Commotion Research (CSCR) +1216:: :: Gigabit Network Economics and Paradigm Shifts +1208:: :: A Glossary of Networking Terms +1207:: :: Answers to Commonly asked ``Experienced Internet User'' + Questions +1206:: :: FYI on Questions and Answers - Answers to Commonly + asked ``New Internet User'' Questions +1200:: S:: IAB Official Protocol Standards +1199:: I:: Request for Comments Summary RFC Numbers 1100-1199 +1198:: I:: FYI on the X Window System +1192:: :: Commercialization of the Internet Summary Report +1181:: :: RIPE Terms of Reference +1180:: :: A TCP/IP Tutorial +1178:: :: Choosing a Name for Your Computer +1177:: :: FYI on Questions and Answers - Answers to Commonly + Asked ``New Internet User'' Questions +1175:: :: FYI on Where to Start - A Bibliography of + Internetworking Information +1174:: I:: "IAB Recommended Policy on Distributing Internet + Identifier Assignment and IAB Recommended Policy Change + to Internet ""Connected"" Status" +1173:: :: "Responsibilities of Host and Network Managers + Summary of the ""Oral Tradition"" of the Internet" +1169:: :: Explaining the Role of GOSIP +1167:: :: Thoughts on the National Research and Education Network +1160:: :: The Internet Activities Board +1152:: :: Workshop Report +1150:: I:: F.Y.I. on F.Y.I. +1149:: :: A Standard for the Transmission of IP Datagrams + on Avian Carriers +1147:: I:: FYI on a Network Management Tool Catalog +1140:: S:: IAB Official Protocol Standards +1135:: :: Helminthiasis of the Internet +1130:: S:: IAB official protocol standards +1127:: :: Perspective on the Host Requirements RFCs +1121:: :: Act one - the poems +1120:: :: Internet Activities Board +1118:: :: Hitchhikers guide to the Internet +1117:: :: Internet numbers +1111:: :: Request for comments on Request for Comments +1100:: S:: IAB official protocol standards +1099:: I:: Request for Comments Summary RFC Numbers 1000-1099 +1093:: :: NSFNET routing architecture +1087:: :: Ethics and the Internet +1083:: S:: IAB official protocol standards +1077:: :: Critical issues in high bandwidth networking +1076:: :: HEMS monitoring and control language +1060:: S:: ASSIGNED NUMBERS +1039:: :: DoD statement on Open Systems Interconnection protocols +1020:: :: Internet numbers +1019:: :: Report of the Workshop on Environments for + Computational Mathematics +1018:: :: Some comments on SQuID +1017:: :: Network requirements for scientific research +1015:: :: Implementation plan for interagency research Internet +1014:: :: XDR +1000:: :: Request For Comments reference guide + 999:: :: Requests For Comments summary notes + 997:: :: Internet numbers + 992:: :: On communication support for fault tolerant process groups + 991:: S:: Official ARPA-Internet protocols + 990:: :: Assigned numbers + 980:: :: Protocol document order information + 979:: :: PSN End-to-End functional specification + 968:: :: Twas the night before start-up + 967:: :: All victims together + 961:: S:: Official ARPA-Internet protocols + 960:: :: Assigned numbers + 945:: :: DoD statement on the NRC report + 944:: S:: Official ARPA-Internet protocols + 943:: :: Assigned numbers + 939:: :: Executive summary of the NRC report on transport + protocols for Department of Defense data networks + 938:: E:: Internet Reliable Transaction Protocol functional + and interface specification + 928:: :: Introduction to proposed DoD standard H-FP + 923:: :: Assigned numbers + 909:: E:: Loader Debugger Protocol + 908:: E:: Reliable Data Protocol + 902:: :: ARPA Internet Protocol policy + 901:: S:: Official ARPA-Internet protocols + 900:: :: Assigned Numbers + 899:: :: Request For Comments summary notes + 880:: S:: Official protocols + 873:: :: Illusion of vendor support + 870:: :: Assigned numbers + 869:: H:: Host Monitoring Protocol + 852:: :: ARPANET short blocking feature + 847:: :: Summary of Smallberg surveys + 846:: :: Who talks TCP? - survey of 22 February 1983 + 845:: :: Who talks TCP? - survey of 15 February 1983 + 844:: :: "Who talks ICMP, too? - Survey of 18 February 1983" + 843:: :: Who talks TCP? - survey of 8 February 83 + 842:: :: Who talks TCP? - survey of 1 February 83 + 840:: S:: Official protocols + 839:: :: Who talks TCP? + 838:: :: Who talks TCP? + 837:: :: Who talks TCP? + 836:: :: Who talks TCP? + 835:: :: Who talks TCP? + 834:: :: Who talks TCP? + 833:: :: Who talks TCP? + 832:: :: Who talks TCP? + 831:: :: Backup access to the European side of SATNET + 828:: :: "Data communications + 825:: :: Request for comments on Requests For Comments + 820:: :: Assigned numbers + 817:: :: Modularity and efficiency in protocol implementation + 816:: :: Fault isolation and recovery + 806:: :: Proposed Federal Information Processing Standard + 800:: :: Request For Comments summary notes + 794:: :: Pre-emption + 790:: :: Assigned numbers + 776:: :: Assigned numbers + 774:: :: Internet Protocol Handbook + 770:: :: Assigned numbers + 766:: :: Internet Protocol Handbook + 762:: :: Assigned numbers + 758:: :: Assigned numbers + 755:: :: Assigned numbers + 750:: :: Assigned numbers + 745:: :: JANUS interface specifications + 739:: :: Assigned numbers + 717:: :: Assigned network numbers + 716:: :: Interim revision to Appendix F of BBN 1822 + 708:: :: Elements of a distributed programming system + 705:: :: Front-end Protocol B6700 version + 700:: :: Protocol experiment + 699:: :: Request For Comments summary notes + 694:: :: Protocol information + 686:: :: Leaving well enough alone + 684:: :: Commentary on procedure calling as a network protocol + 681:: :: Network UNIX + 678:: :: Standard file formats + 677:: :: Maintenance of duplicate databases + 672:: :: Multi-site data collection facility + 671:: :: Note on Reconnection Protocol + 667:: :: BBN host ports + 666:: :: Specification of the Unified User-Level Protocol + 663:: :: Lost message detection and recovery protocol + 661:: :: Protocol information + 645:: :: Network Standard Data Specification syntax + 643:: :: Network Debugging Protocol + 642:: :: Ready line philosophy and implementation + 638:: :: IMP/TIP preventive maintenance schedule + 637:: :: Change of network address for SU-DSL + 635:: :: Assessment of ARPANET protocols + 634:: :: Change in network address for Haskins Lab + 631:: :: International meeting on minicomputers and data + communication + 629:: :: Scenario for using the Network Journal + 628:: :: Status of RFC numbers and a note on pre-assigned + journal numbers + 621:: :: NIC user directories at SRI ARC + 617:: :: Note on socket number assignment + 609:: :: Statement of upcoming move of NIC/NLS service + 604:: :: Assigned link numbers + 603:: :: Response to RFC 597 + 602:: :: The stockings were hung by the chimney with care + 598:: :: "RFC index - December 5, 1973" + 597:: :: Host status + 590:: :: MULTICS address change + 588:: :: London node is now up + 585:: :: ARPANET users interest working group meeting + 584:: :: Charter for ARPANET Users Interest Working Group + 582:: :: Comments on RFC 580 + 581:: :: Corrections to RFC 560 + 580:: :: Note to protocol designers and implementers + 578:: :: Using MIT-Mathlab MACSYMA from MIT-DMS Muddle + 569:: H:: NETED + 552:: :: Single access to standard protocols + 547:: :: Change to the Very Distant Host specification + 544:: :: Locating on-line documentation at SRI-ARC + 537:: :: Announcement of NGG meeting July 16-17 + 530:: :: Report on the Survey project + 529:: :: Note on protocol synch sequences + 527:: :: ARPAWOCKY + 526:: :: Technical meeting + 523:: :: SURVEY is in operation again + 519:: :: Resource evaluation + 518:: :: ARPANET accounts + 515:: :: Specifications for datalanguage + 503:: :: Socket number list + 496:: :: TNLS quick reference card is available + 494:: :: Availability of MIX and MIXAL in the Network + 492:: :: Response to RFC 467 + 491:: :: "What is ""Free""?" + 483:: :: Cancellation of the resource notebook framework meeting + 474:: :: Announcement of NGWG meeting + 464:: :: Resource notebook framework + 462:: :: Responding to user needs + 457:: :: TIPUG + 456:: :: Memorandum + 441:: :: Inter-Entity Communication - an experiment + 440:: :: Scheduled network software maintenance + 439:: :: PARRY encounters the DOCTOR + 433:: :: Socket number list + 432:: :: Network logical map + 425:: :: But my NCP costs $500 a day + 419:: :: To + 405:: :: Correction to RFC 404 + 404:: :: Host address changes involving Rand and ISI + 403:: :: Desirability of a network 1108 service + 402:: :: ARPA Network mailing lists + 401:: :: Conversion of NGP-0 coordinates to device specific + coordinates + 390:: :: TSO scenario + 379:: :: Using TSO at CCN + 376:: :: Network host status + 372:: :: Notes on a conversation with Bob Kahn on the ICCC + 371:: :: Demonstration at International Computer Communications + Conference + 370:: :: Network host status + 363:: :: ARPA Network mailing lists + 356:: :: ARPA Network Control Center + 355:: :: Response to NWG/RFC 346 + 350:: :: User accounts for UCSB On-Line System + 349:: :: Proposed standard socket numbers + 345:: :: Interest in mixed integer programming MPSX on NIC + 360/91 at CCN + 334:: :: Network use on May 8 + 331:: :: IMP System change notification + 330:: :: Network host status + 329:: :: ARPA Network mailing lists + 327:: :: Data and File Transfer workshop notes + 322:: :: Well known socket numbers + 321:: :: CBI networking activity at MITRE + 320:: :: Workshop on hard copy line printers + 319:: :: Network host status + 317:: :: Official Host-Host Protocol modification + 316:: :: ARPA Network Data Management Working Group + 315:: :: Network host status + 313:: :: Computer based instruction + 305:: :: Unknown host numbers + 303:: :: ARPA Network mailing lists + 295:: :: "Report of the Protocol Workshop, 12 October 1971" + 291:: :: Data management meeting announcement + 290:: :: Computer networks and data sharing + 282:: :: Graphics meeting report + 276:: :: NIC course + 270:: :: Correction to BBN Report No. 1822 NIC NO 7958 + 269:: :: Some experience with file transfer + 263:: :: Very Distant Host interface + 256:: :: IMPSYS change notification + 254:: :: Scenarios for using ARPANET computers + 253:: :: Second Network Graphics meeting details + 249:: :: Coordination of equipment and supplies purchase + 246:: :: Network Graphics meeting + 245:: :: Reservations for Network Group meeting + 243:: :: Network and data sharing bibliography + 242:: :: Data descriptive language for shared data + 240:: :: Site status + 239:: :: Host mnemonics proposed in RFC 226 NIC 7625 + 235:: :: Site status + 234:: :: Network Working Group meeting schedule + 232:: :: Postponement of network graphics meeting + 228:: :: Clarification + 225:: :: Rand/UCSB network graphics experiment + 223:: :: Network Information Center schedule for network users + 219:: :: User's view of the datacomputer + 218:: :: Changing the IMP status reporting facility + 214:: :: Network checkpoint + 213:: :: IMP System change notification + 211:: :: ARPA Network mailing lists + 209:: :: Host/IMP interface documentation + 208:: :: Address tables + 207:: :: September Network Working Group meeting + 204:: :: Sockets in use + 200:: :: RFC list by number + 198:: :: Site certification - Lincoln Labs 360/67 + 195:: :: Data computers-data descriptions and access language + 194:: :: Data Reconfiguration Service - compiler/interpreter + implementation notes + 187:: :: Network/440 protocol concept + 186:: :: Network graphics loader + 185:: :: NIC distribution of manuals and handbooks + 182:: :: Compilation of list of relevant site reports + 180:: :: File system questionnaire + 179:: :: Link number assignments + 173:: :: Network data management committee meeting announcement + 171:: :: Data Transfer Protocol + 170:: :: RFC list by number + 169:: :: Computer networks + 168:: :: ARPA Network mailing lists + 167:: :: Socket conventions reconsidered + 164:: :: "Minutes of Network Working Group meeting, 5/16 + through 5/19/71 " + 162:: :: NETBUGGER3 + 160:: :: RFC brief list + 157:: :: Invitation to the Second Symposium on Problems in the + Optimization of Data Communications Systems + 155:: :: ARPA Network mailing lists + 154:: :: Exposition style + 149:: :: Best laid plans + 148:: :: Comments on RFC 123 + 147:: :: Definition of a socket + 140:: :: Agenda for the May NWG meeting + 138:: :: Status report on proposed Data Reconfiguration Service + 136:: :: Host accounting and administrative procedures + 135:: :: Response to NWG/RFC 110 + 132:: :: Typographical error in RFC 107 + 131:: :: Response to RFC 116 + 130:: :: Response to RFC 111 + 129:: :: Request for comments on socket name structure + 126:: :: Graphics facilities at Ames Research Center + 124:: :: Typographical error in RFC 107 + 121:: :: Network on-line operators + 120:: :: Network PL1 subprograms + 119:: :: Network Fortran subprograms + 118:: :: Recommendations for facility documentation + 117:: :: Some comments on the official protocol + 116:: :: Structure of the May NWG meeting + 115:: :: Some Network Information Center policies on handling + documents + 113:: :: Network activity report + 112:: :: User/Server Site Protocol + 111:: :: Pressure from the chairman + 109:: :: Level III Server Protocol for the Lincoln Laboratory + NIC 360/67 Host + 108:: :: "Attendance list at the Urbana NWG meeting, February + 17-19,1971 " + 107:: :: Output of the Host-Host Protocol glitch cleaning committee + 106:: :: User/Server Site Protocol network host questionnaire + 104:: :: Link 191 + 103:: :: Implementation of interrupt keys + 102:: :: Output of the Host-Host Protocol glitch cleaning committee + 101:: :: "Notes on the Network Working Group meeting, + Urbana, Illinois, February 17, 1971" + 100:: :: Categorization and guide to NWG/RFCs + 99:: :: Network meeting + 95:: :: Distribution of NWG/RFC's through the NIC + 90:: :: CCN as a network service center + 89:: :: Some historic moments in networking + 87:: :: Topic for discussion at the next Network Working Group + meeting + 85:: :: Network Working Group meeting + 84:: :: List of NWG/RFC's 1-80 + 82:: :: Network meeting notes + 81:: :: Request for reference information + 78:: :: NCP status report + 77:: :: Network meeting report + 76:: :: Connection by name + 75:: :: Network meeting + 74:: :: Specifications for network use of the UCSB On-Line System + 73:: :: Response to NWG/RFC 67 + 72:: :: Proposed moratorium on changes to network protocol + 71:: :: Reallocation in case of input error + 69:: :: Distribution list change for MIT + 68:: :: "Comments on memory allocation control commands + 66:: :: NIC - third level ideas and other noise + 64:: :: Getting rid of marking + 63:: :: Belated network meeting report + 61:: :: Note on interprocess communication in a resource + sharing computer network + 57:: :: Thoughts and reflections on NWG/RFC 54 + 52:: :: Updated distribution list + 51:: :: Proposal for a Network Interchange Language + 50:: :: Comments on the Meyer proposal + 49:: :: Conversations with S. Crocker UCLA + 48:: :: Possible protocol plateau + 47:: :: BBN's comments on NWG/RFC #33 + 46:: :: ARPA Network protocol notes + 45:: :: New protocol is coming + 44:: :: Comments on NWG/RFC 33 and 36 + 43:: :: Proposed meeting [LIL] + 40:: :: More comments on the forthcoming protocol + 39:: :: Comments on protocol re + 37:: :: "Network meeting epilogue, etc" + 36:: :: Protocol notes + 35:: :: Network meeting + 34:: :: Some brief preliminary notes on the Augmentation + Research Center clock + 31:: :: Binary message forms in computer + 30:: :: Documentation conventions + 27:: :: Documentation conventions + 25:: :: No high link numbers + 24:: :: Documentation conventions + 21:: :: Network meeting + 16:: :: M.I.T + 15:: :: Network subsystem for time sharing hosts + 13:: :: [Referring to NWG/RFC 11] + 11:: :: Implementation of the Host-Host software procedures + in GORDO + 10:: :: Documentation conventions + 9:: :: Host software + 8:: :: Functional specifications for the ARPA Network + 7:: :: Host-IMP interface + 6:: :: Conversation with Bob Kahn + 5:: :: Decode Encode Language + 4:: :: Network timetable + 3:: :: Documentation conventions + 2:: :: Host software + 1:: :: Host software -Appendix A: List of RFC's divided by Area Appendix B: Automatic Script to Implement Methodology + +#!/usr/bin/perl5 + +# Program to read text files (such as RFCs and Internet Drafts) and +# output items that might relate to year 2000 issues, particularly +# 2-digit years. +# +# Version 1.0. By Paul Hoffman (paulh@imc.org). You may distribute and +# use this program freely. I welcome comments and criticisms on the +# program. +# +# Note: In the spirit of quick and dirty, this code is by no means +# optimized for speed or memory usage. Instead, it is written to +# be as easy to read(and therefore debug) as possible. + +# Some people like using disk files, others like STDIN and STDOUT. +# This program accomodates both types. 'file' means input comes +# from the first argument on the command line, output goes to that +# filename with a ".out" extension; 'std' means STDIN and STDOUT. + +$UsageType = 'file'; # Should be 'file' or 'std' +@CheckWords = qw(UTCTime two-digit 2-digit 2digit century 1900 2000); +# You might want to add "year yyyy" to this list, but then a +# large proportion of the RFCs and drafts get selected + +if($UsageType eq 'file') { + if($ARGV[0] eq '') + { die "You must specify the name of the file to open.\n" } + $InName = $ARGV[0]; + unless(-r $InName) { die "Could not read $InName.\n" } + open(IN, $InName) or die "Could not open $InName.\n"; + $OutName = "$InName.out"; + open(OUT, ">$OutName") or die "Could not write to $OutName.\n"; + $OutStuff = ''; # Holder for what we're going to print out +} else { # Do STDIN and STDOUT + open(IN, "-"); open(OUT, ">-"); +} + +# Read the whole file into an array. This is a tad wasteful of memory +# but makes the output easier. +@All = (); +while() { push(@All, $_) } +$LastLine = $#All; + +# Process the instance of "yy" not followed by "yy" +for($i = 0; $i <= $LastLine; $i += 1 ) { + next unless(grep(/yy/i, $All[$i])); + next if(grep(/yyyy/i, $All[$i])); + &PrintFive($i, "'yy' on a line without 'yyyy'"); +} + +# Next do the words that should cause extra concern +foreach $Word (@CheckWords) { + for($i = 0; $i <= $LastLine; $i += 1 ) { + next unless(grep(/$Word/i, $All[$i])); + &PrintFive($i, "$Word"); + } +} + +# All done. If writing to a file, and nothing got written, delete the +# file so that you can quickly scan for the ".out" files. +if($UsageType eq 'file') { + if(length($OutStuff) > 0) { + $OutStuff = "+=+=+=+=+= File $InName +=+=+=+=+= \n + $OutStuff\n"; + print OUT $OutStuff; close(OUT); + } else { # Nothing to put in the .out + close(OUT); + unlink($OutName) or die "Couldn't unlink $OutName\n"; + } +} +exit; + +sub PrintFive { + my $Where = shift(@_); my $Msg = shift(@_); + my ($WhereRealLine, $Start, $End, $j); + + $WhereRealLine = $Where + 1; + $OutStuff .= "$Msg found at line $WhereRealLine:\n"; + $Start = $Where - 2; $End = $Where + 2; + if($Where < 2) { $Start = 0 } + if($Where > $LastLine - 2) { $End = $LastLine } + for($j = $Start; $j <= $End; $j += 1) { $OutStuff .= "$j: " + . @All[$j] } + $OutStuff .= "\n"; +} + Appendix C: Output of the script in Appendix B on all RFC's from 1 through 2134 + ++=+=+=+=+= File rfc90.txt +=+=+=+=+= +2000 found at line 71: +68: consoles); +69: +70: j) Six data communication ports (3 dial @ 2000 baud, +71: 1 dedicated @ 4800 baud, and 2 dedicated @ 50,000 +72: baud) for remote batch entry terminals; + ++=+=+=+=+= File rfc230.txt +=+=+=+=+= +2000 found at line 92: +89: as for conventional synchronous block communication, since start and +90: stop bits for each character would need to be transmitted. This loss +91: is not substantial and does occur now for 2000 bps TIP-terminal +92: communication. +93: + +2000 found at line 134: +131: 92 transmitting sites in the U.S. and Canada were used with standard +132: Bell System Dataphone datasets used at both ends. At both 1200 and +133: 2000 bps, approximately 82% of the calls had error rates of 1 error in +134: 10^5 bits or better, assuming an equal number of short, medium, and +135: long hauls. + ++=+=+=+=+= File rfc241.txt +=+=+=+=+= +2000 found at line 32: +29: justifiable on the basis that the IMP and Host computers were +30: expected to be either in the same room (up to 30 feet of cable) or, +31: via the Distant Host option, within 2000 feet on well- controlled, +32: shielded cables. A connection through common carrier facilities is +33: not comparably free of errors. Usage of common- carrier lines for + ++=+=+=+=+= File rfc263.txt +=+=+=+=+= +2000 found at line 22: +19: of the occasional desire to interface a Host to some IMP via a +20: long-distance connection (where long-distance, in this context, +21: is any cable run longer than 2000 feet but may typically be tens +22: of miles) via either a hard-wire or telephone circuit. We believe +23: that any good solution to the general problem of interfacing Hosts + ++=+=+=+=+= File rfc662.txt +=+=+=+=+= +2000 found at line 143: +140: by a rather short cable (approximately 100 feet long.) The CISL Multics is +141: connected to the IMP number 6 (port 0) by an approximately l5OO feet long cable. +142: 8oth IMPs are in close physical proximity (approximately 2000 feet,) and are +143: connected to each other by a 5O kilobits per second line. The results given +144: above show considerable improvement in the performance with the new IMP DIM. + ++=+=+=+=+= File rfc713.txt +=+=+=+=+= +2000 found at line 830: +827: succeeding bytes in the stream used to encode the object. +828: +829: A data object requiring 20000 (47040 octal) bytes would +830: appear in the stream as follows. +831: + +2000 found at line 837: +834: 10000010 -- specifying that the next 2 bytes +835: contain the stream length +836: 01001110 -- first byte of number 20000 +837: 00100000 -- second byte +838: . + +2000 found at line 845: +842: . +843: +844: Interpretation of the contents of the 20000 bytes in +845: the stream can be performed by a module which knows the +846: specific format of the non-atomic type specified by DEFGH in + ++=+=+=+=+= File rfc724.txt +=+=+=+=+= +2-digit found at line 1046: +1043: <4-digit-year> +1044: ::= "/" +1045: "/" <2-digit-year> +1046: ::= +1047: ::= + +2-digit found at line 1062: +1059: | "December" | "Dec" +1060: <4-digit-year> ::= +1061: <2-digit-year> ::= +1062: