--- 1/draft-ietf-2000-issue-01.txt 2008-04-11 10:37:45.000000000 +0200 +++ 2/draft-ietf-2000-issue-02.txt 2008-04-11 10:37:45.000000000 +0200 @@ -1,47 +1,47 @@ Network Working Group Philip J. Nesser II Editor -draft-ietf-2000-issue-01.txt Nesser & Nesser Consulting +draft-ietf-2000-issue-02.txt Nesser & Nesser Consulting The Internet and the Millenium 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". + Drafts as reference material or to cite them other than as a "working + draft" or "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract The Year 2000 Working Group(WG) has conducted an investigation into the millenium problem as it regards Internet related protocols. This investigation only targeted the protocols as documented in the Request For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost all Internet protocols were given a clean bill of health. Several cases -of "period" problems were discussed where a time field would "roll -over" as the size of field was reached. In particular, there are +of ''period'' problems were discussed where a time field would ''roll +over'' as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation. 1.0 Introduction According to the trade press billions of dollars will be spend the upcoming three years on the year 2000 problem, also called the @@ -65,40 +65,38 @@ that all over the Internet people will redo the same inventory over and over again the WG is to make an inventory of all important Internet protocols and their most popular implementations with respect to the millenium problem. Only software and protocols directly related to the Internet will be considered. 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, 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. +Kubinec, Michael Patton, Chris Newman, Erik-Jan Bos, Paul Hoffman, +and Rick H. Wesson. The pace with which this group has operated has +only been achievable by the intimate familiarity of the contributors +with the protocols and ready access to the collective knowledge of the +IETF. Disclaimer This RFC is not complete. It is an effort to analyze the Y2K impact on hundreds of protocols but is likely to have missed some protocols and misunderstood others. Organizations should not attempt to claim any legitimacy or approval for any particular protocol based on this document. The efforts have concentrated on the identification of potential problems, rather than solutions to any of the problems that have been identified. Any proposed solutions are only that: proposed. A formal engineering review should take place before any solution is adopted. -<> - Methodology The first task was dividing the types of RFC's into logical groups rather than the strict numeric publishing order. Fifteen specific areas were identified. They are: "Autoconfiguration" , "Directory Services", "Disk Sharing", "Games and Chat" ,"Information Services & File Transfer", "Network & Transport Layer", "Electronic Mail", "NTP", Name Serving", "Network Management", "News", "Real Time Services", "Routing", "Security", and "Virtual Terminal". In addition to these categories many hundreds of RFC's were immediately eliminated because @@ -142,26 +140,65 @@ 2.0 Autoconfiguration 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. - -<< EDITOR'S NOTE: We still need DHCP investigation.>> +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. Specifics +The following RFCs were examined for possible millenium problems: 906, +951, 1048, 1084, 1395, 1497, 1531, 1532, 1533, 1534, 1541, 1542, 1970, & +1971. RFC 951's only reference to time or dates is a two byte filed in +the packet which is number of second since the hosts was booted. RFC's +1048, 1084, 1395, 1497, 1531, & 1532 have either no references to dates +and time, or they are the same as the RFCs which obsoleted them discuessed +in the next paragraph. + +RFC 1533 enumerates all the known DHCP field types and a number of these have +to do with time. Section 3.4 defines a "Time Offset" field which specifies +the offset of the clients subnet in seconds from UTC. This 4 byte field +has no millenium issues. Section 9.2 defines the IP Address Lease Time field +which is used by clients to request a specific lease time. This four byte +field is an unsigned integer containing a number of seconds. Section 9.9 +defines a Renewal Time Value field, Section 9.10 defines a Rebinding Time Value, +both of which are similarly 32 bit fields which have no millenium issues. + +RFC 1534 has no references to times or dates. + +RFC 1541 has two mentions of times/dates. The first is the "secs" field which, +similarly to RFC 951, is a 16 bit field for the number of seconds since the host +has booted. There is also a discussion in section 3.3 about "Interpretation and +Representation of Time Values" which while clearly states that there is no +millenium or period problems. + +RFC 1542 also references the "secs" field mentioned previously. + +"Router Advertisment Message Format" the following fields are defined: Router +Lifetime, Reachable Time, & Retrans Timer. In section 4.6.2 "Prefix Information" +the following are defined: Valid Lifetime, & Prefered Lifetime. In section +6.2.1 "Router Configuration Variables the following are defined: MaxRtrAdvInterval, +MinRtrAdvInterval, AdvReachableTime, AdvRetransTimer, AdvDefaultLifetime, +AdvValidLifetime, & AdvPreferredLifetime. All of these fields specify counters +of some sort which have no millenium or periodicity problems. + +RFC 1971 has some discussion of preferred lifetimes, depreciated lifetimes and +valide lifetimes of leases, but only discusses them in an expository way. + 3.0 Directory Services 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 @@ -194,40 +231,45 @@ 4.0 Disk Sharing 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. -Specifics +After careful review, NFS has no year 2000 problems. -The reference to time in this protocol is to set the length of -time to wait for the first try of a request; timeout. Timeout time -in the NFS protocol is calculated rather than preserved. As such, -is not affected by the date. +Specifics -SUN Microsystems states that there is known problem associated with -this protocol and the millennium change. +The reference to time in this protocol are the times of file data +modification, file access, and file metadata change (mtime, atime, and +time, respectively). These times are kept as 32 bit unsigned +quantities in seconds since 1970-01-01, and so the NFS protocol will +not experience an Epoch event until the year 2106. 5.0 Games and Chat Summary The RFC's which were categorized into this group were related to the -Internet Relay Chat Protocol (IRC). +Internet Relay Chat Protocol (IRC). No millenium problems exist in the +IRC protocol. Specifics -<> +There is only a single instance of time or date related information in the +IRC protocol as specified by RFC 1459. Section 4.3.4 defines a TIME message +type which queries a server for its local time. No mention is made of the +format of the repy or how it is parsed, the assumption being specific +implementations will handle the reply and parse it appropriately. 6.0 Information Services & File Transfer 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 @@ -425,21 +467,21 @@ will "roll over" at Thu Feb 07 00:54:54 2036 GMT. Since NTP is the current defacto standard for network time this does not seem to be an issue. Specifics There is no reference anywhere in the NTP specification or implementation to any reference epoch other than 1 January 1900. In short, NTP doesn't know anything about the millennium. ->From the Time Protocol RFC (868): +From the Time Protocol RFC (868): S: Send the time as a 32 bit binary number. ... The time is the number of seconds since 00:00 (midnight) 1 January 1900 GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this base will serve until the year 2036. 10.0 Name Services