--- 1/draft-ietf-2000-issue-03.txt 2007-12-18 18:35:09.000000000 +0100 +++ 2/draft-ietf-2000-issue-04.txt 2007-12-18 18:35:09.000000000 +0100 @@ -1,12 +1,13 @@ + Network Working Group Philip J. Nesser II -draft-ietf-2000-issue-03.txt Nesser & Nesser Consulting +draft-ietf-2000-issue-04.txt Nesser & Nesser Consulting The Internet and the Millennium Problem (Year 2000) Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six @@ -57,20 +58,35 @@ 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. +This document is divided into a number of sections. Section 1 is +the Introduction which you are now reading. Section 2 is a +disclaimer about the completeness of this effort. Section 3 +describes areas in which millenium problems have been found, while +Section 4 describes a few other "period" problems. Section 5 +describes potential fixes to problems that have been identified. +Section 6 describes the methodology used in the investigation. +Sections 7 through 22 are devoted to the 15 different groupings of +protocols and RFCs. Section 23 discusses security considerations, +Section 24 is devoted to references, and Section 25 is the author +contact information. Appendix A is the list of RFCs examined +broken down by category. Appendix B is a PERL program used to make +a first cut identification of problems, and Appendix C is the output +of that PERL program. + 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. @@ -100,21 +116,21 @@ 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 +Here is a brief description of all the Millennium 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. @@ -130,25 +146,25 @@ 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. +potential millennium 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. +which is subject to millennium 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 @@ -192,21 +208,21 @@ 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. +have a Millennium issue. 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. @@ -463,25 +479,25 @@ 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. +potential millennium 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. +which is subject to millennium 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 @@ -524,61 +540,61 @@ 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. +potential millennium 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. +which is subject to millennium 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. +size of a message but has no millennium 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. +references to dates or times, and hence no millennium 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 @@ -586,91 +602,91 @@ 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. +millennium or year 2000 problems were found. 12.2 Specifics 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. +millennium 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. +millennium 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. +experience any millennium 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. +any millennium or year 2000 issues. RFC 1661 on PPP defines three timers in Section 4.6, none of which have any year 2000 issues. and the extended timers recommended in it. RFC 1575 defines an echo function for CNLP discusses in the narrative the use of the Lifetime Field in Section 5.3. There is nothing to suggest that there is any year 2000 issues. RFC 1329 on Dual MAC FDDI Networks discusses ARP cache administration in Section 9.3 and 9.4 and various timers to expire entries. RFC 1256 on ICMP Router Discovery Messages talks about lifetime fields in Section 2 and defines three router configuration variables in Section -4.1. None of these have any millenium issues. +4.1. None of these have any millennium 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 @@ -695,28 +711,28 @@ 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. +millennium 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 +22, 20, 19, 17, 12 were deemed too old to be considered for millennium 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. @@ -735,21 +751,21 @@ 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 +Internet today, but IMAP version 4 has already taken 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. @@ -954,32 +970,32 @@ 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 +time based on the original frame so once again there is no millennium 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. +have any millennium 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 @@ -995,27 +1011,27 @@ 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 +timer expiration in section 5, neither of which have any millennium 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 +gives examples values for these fields, which indicate no millennium 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. @@ -1041,88 +1057,88 @@ 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 +millennium, 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. +section 2.6, none of which have any millennium 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. +Message (Section 4.1). There are no millennium 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. +no known issues regarding BGP and the millennium. 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 +also defines the Inactivity Timer. No millennium 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. +same timers as noted above, with the same lack of a millennium 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 +7 to time values. None of the timers have any millennium 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 +RFC 1058 on RIP discusses the 30-second timers in section 3.3. There is no millennium 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. +of these timers suffer from the millennium 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, @@ -1145,38 +1161,38 @@ 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 +have a Millennium issue since the year specification only provides the last two digits of the year. -20,2 Specifics +20.2 Specifics -RFC 2082 on RIP-2 MD% Authentication requires storage of security keys +RFC 2082 on RIP-2 MD5 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. +millennium 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 +1123 formats which is not subject to millennium 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. @@ -1274,41 +1290,41 @@ 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. +millennium 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 +found to have any date or time references, let alone millennium 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. @@ -3728,33 +3744,32 @@ 7:: :: Host-IMP interface 6:: :: Conversation with Bob Kahn 5:: :: Decode Encode Language 4:: :: Network timetable 3:: :: Documentation conventions 2:: :: Host software 1:: :: Host software Appendix B: Automatic Script to Implement Methodology -#!/usr/bin/perl5 +#!/usr/bin/perl # Program to read text files (such as RFCs and Internet Drafts) and # output items that might relate to year 2000 issues, particularly # 2-digit years. -# -# Version 1.0. By Paul Hoffman (paulh@imc.org). You may distribute and -# use this program freely. I welcome comments and criticisms on the -# program. -# -# Note: In the spirit of quick and dirty, this code is by no means -# optimized for speed or memory usage. Instead, it is written to -# be as easy to read(and therefore debug) as possible. + +# Version 1.0. By Paul Hoffman (phoffman@imc.org). This is a +# quick-and-dirty hack and could be written more elegantly and +# more efficiently. There is a known bug in the line number +# reporting, and there are probably other bugs as well. +# Use this code at your own risk. This code may be freely +# redistributed. # Some people like using disk files, others like STDIN and STDOUT. # This program accomodates both types. 'file' means input comes # from the first argument on the command line, output goes to that # filename with a ".out" extension; 'std' means STDIN and STDOUT. $UsageType = 'file'; # Should be 'file' or 'std' @CheckWords = qw(UTCTime two-digit 2-digit 2digit century 1900 2000); # You might want to add "year yyyy" to this list, but then a # large proportion of the RFCs and drafts get selected