rfc2626.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,531 行 · 第 1/5 页

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.




Nesser                       Informational                      [Page 1]

RFC 2626  The Internet and the Millennium Problem (Year 2000)  June 1999


   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



Nesser                       Informational                      [Page 2]

RFC 2626  The Internet and the Millennium Problem (Year 2000)  June 1999


   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.






Nesser                       Informational                      [Page 3]

RFC 2626  The Internet and the Millennium Problem (Year 2000)  June 1999


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



Nesser                       Informational                      [Page 4]

RFC 2626  The Internet and the Millennium Problem (Year 2000)  June 1999


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,



Nesser                       Informational                      [Page 5]

RFC 2626  The Internet and the Millennium Problem (Year 2000)  June 1999


   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,