rfc2626.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,531 行 · 第 1/5 页

   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.



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


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.




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


   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.





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


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

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.



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


   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.



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


   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.

19. Routing

19.1 Summary

   The RFC's which were categorized into this group were Routing
   Information Protocol (RIP), the Open Shortest Path First (OSPF)
   protocol, Classless InterDomain Routing (CIDR),the Border Gateway
   Protocol (BGP), and the InterDomain Routing Protocol (IDRP).

   After careful examination both BGP and RIP have been found Year 2000
   compliant.

   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.

   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