tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2626

 Errata 
Informational
Pages: 275
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     No Next: Highest Number in Group     Group: 2000

The Internet and the Millennium Problem (Year 2000)

Part 1 of 9, p. 1 to 22
None       Next RFC Part

 


Top       Page 1 
Network Working Group                                     P. Nesser II
Request for Comments: 2626                  Nesser & Nesser Consulting
Category: Informational                                      June 1999


          The Internet and the Millennium Problem (Year 2000)


Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

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.

Top       Page 2 
   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.

   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.

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

Top       Page 3 
   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 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.
       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.

Top       Page 4 
   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 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 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
   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"

   Version 2 of SNMP's MIB definition language (SMIv2) specifies the use
   of UCTTimes for time stamping MIB modules.  Even though these time
   stamps do not flow in any network protocols, there could be as issue
   with management applications, depending on implementations.

3.6  "Network News"

   There does exist a problem in both NNTP, RFC 977, and the Usenet News
   Message Format, RFC 1036.  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.

Top       Page 5 
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 <email-address>
   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 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.
   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. However,

Top       Page 6 
   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.

Top       Page 7 
   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.

Top       Page 8 
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.

Top       Page 9 
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.

Top       Page 10 
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.

Top       Page 11 
   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 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 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

   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 <META> tag allows the embedding of
   recommended values for some HTTP headers, including Expires.  E.g.

       <META HTTP-EQUIV="Expires"
             CONTENT="Tue, 04 Dec 1993 21:29:02 GMT">

   Servers should rewrite these dates into RFC1123 format if necessary.

Top       Page 12 
   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 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 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 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.

Top       Page 13 
   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 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

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
   millennium 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
   millennium issues.

Top       Page 14 
   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 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 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 millennium 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.

Top       Page 15 
   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 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 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
   millennium references.

Top       Page 16 
   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 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.

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

Top       Page 17 
   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.

Top       Page 18 
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 over TCP/IP (CMOT).

   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.

Top       Page 19 
   The standards for CMOT 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

   Management applications that store and use MIB modules need to be
   smart about interpreting these UTCTimes, by prepending a "19" or a
   "20" as appropriate.

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.

Top       Page 20 
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 1036.  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.

Top       Page 21 
   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 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 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
   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.

Top       Page 22 
   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 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 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.



(page 22 continued on part 2)

Next RFC Part