rfc2626.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,531 行 · 第 1/5 页

   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.




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


   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.








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


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.





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


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.




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


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.




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


   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.