Network Working Group Philip J. Nesser II draft-ietf-2000-issue-03.txt Nesser & Nesser Consulting Internet Draft July 1998 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 Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet 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 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. Introduction According to the trade press billions of dollars will be spend the 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 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, 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 IETF. 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 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. 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. 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", "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 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. 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. 7. Autoconfiguration 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. 7.2 Specifics 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 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 millennium or period problems. RFC 1542 also references the "secs" field mentioned previously. 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 valid lifetimes of leases, but only discusses them in an expository way. 8. Directory Services 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 specific portion of this section. 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 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 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. 9. Disk Sharing 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. 9.2 Specifics 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. 10. Games and Chat 10.1 Summary The RFC's which were categorized into this group were related to the Internet Relay Chat Protocol (IRC). No millennium problems exist in the IRC protocol. 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 reply or how it is parsed, the assumption being specific implementations will handle the reply and parse it appropriately. 11. Information Services & File Transfer 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 Protocol and the LPD protocol. 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, 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. 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: 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. 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. 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. In RFC 1866, on HTML 2.0,the tag allows the embedding of recommended values for some HTTP headers, including Expires. E.g. Servers should rewrite these dates into RFC1123 format if necessary. RFC 1807 defines a format for bibliographic records and it specifies a DATE format, which requires 4 digit year fields. 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. 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. 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 1777 on LDAP defines a timelimit in Section 4.3 which is expressed in seconds, but does not define any limits. 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. 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. 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. RFC 998 on NETBLT defines a Death time in Section 8, which is the sender's death time in seconds. 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. RFC 969 was obsoleted by RFC 998. 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. 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. RFCS below 400 were considered too obsolete to even consider. 12. Network & Transport Layer 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) protocol. A variety of less known protocols were also examined. After careful review of the nearly 400 RFC's in this catagory, no millenium or year 2000 problems were found. 12.2 Specifics RFC 2125 on the PPP Bandwidth Allocation Protocol (BAP) in section 5.3 discusses the use if mandatory timers, but gives no mention as to how they are implemented. 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. RFC 1644 on T/TCP (TCP Extensions for Transactions) mentions RFC 1323 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 standards require four-digit years and are thus not prone to typical Year 2000 problems. 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 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 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. 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. 14. Network Time Protocols 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. 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): 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. 15. Name Services 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.). There have been no year 2000 relayed problems found with the DNS protocols, or common implementations of them. 15.2 Specifics 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. 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). Although a few discrepancies have been found and outlined below, none of them should have an impact on interoperability. 16.2 Specifics 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.) 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 algorithm. This is really a "Year 0" problem rather than a Year 2000 problem, and in any case, CMOT is not currently deployed. 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: 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. 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. 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. 17 Network News 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, 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. 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. 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. 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. 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 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. 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. 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. 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. IDPR suffers from the classic Year 2038 problem, by having a timestamp counter which rolls over at that time. 19.2 Specifics 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. 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. 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. 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. 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. 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. 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. RFC 1504 on Appletalk Update-Based Routing Protocol defines a 10-second period in Section 3, and hence has no relevant issues. 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. 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. RFC 1058 on RIP discusses the 30-second timers in section 3.3. There is no millenium issues related to RIP. 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. RFC 911 on EGP on Berkeley Unix recommend timer values of 30 and 120 seconds. 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. 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. 20. Security 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. 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. 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. 20,2 Specifics 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 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 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. 21.2 Specifics 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. 24. References Because of the exhaustive nature of this investigation, the reader is referred to the list of published RFC's available from the IETF Secretariat or the RFC Editor, rather than republishing them here. 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 Appendix A: List of RFC's for each Area 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