RFC2626 - The Internet and the Millennium Problem (Year 2000)

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 RFC850) 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.
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 RFCis 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.
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 RFC1714
has been updated to fix the problems found. RFC2167 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 RFCobsolete. 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 RFCseries
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 RFC2068, requires all newly generated date
stamps to conform to RFC1123 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.
Html 2.0, as defined in RFC1866, could allow a very suBTle Year 2000
problem, but once again this recommendation has been passed on the
HTML WG.
RFC1778 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.
RFC1440 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 RFC1123 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, RFC977, and the Usenet News
Message Format, RFC10336. 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.
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 RFC1786 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"
RFC1507 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,
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.
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.
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. RFC951"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.
RFC1533 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.
RFC1534 has no references to times or dates.
RFC1541 has two mentions of times/dates. The first is the "secs"
field which, similarly to RFC951, 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.
RFC1542 also references the "secs" field mentioned previously.
RFC1970 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.
RFC1971 has some discussion of preferred lifetimes, depreciated
lifetimes and valid lifetimes of leases, but only discusses them in
an expository way.
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.
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 RFC1459. 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 RFC2068, requires all newly generated date
stamps to conform to RFC1123 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 RFC1866, could allow a very subtle Year 2000
problem, but once again this recommendation has been passed on the
HTML WG.
RFC1778 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.
RFC1440 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 ; RFC822, updated by RFC1123
instead of this RFC850 format:
Sunday, 06-Nov-94 08:49:37 GMT ; RFC850, obsoleted by RFC1036
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.
RFC1986 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 RFC1866, 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.
RFC1807 defines a format for bibliographic records and it specifies
a DATE format, which requires 4 digit year fields.
RFC1788 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.
RFC1784 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.
RFC1778 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.
RFC1777 on LDAP defines a timelimit in Section 4.3 which is
expressed in seconds, but does not define any limits.
RFC1440 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.
RFC1068 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.
RFC1037 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.
RFC998 on NETBLT defines a Death time in Section 8, which is the
sender"s death time in seconds.
RFC978 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.
RFC969 was obsoleted by RFC998.
RFC916 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.
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
RFC2125 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.
RFC2114 on a Data Link Switching Client Access Protocol defines a
retry timer of five seconds in Section 3.4.1.
RFC2097 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.
RFC2075 on the IP Echo Host Service discusses timestamps and has no
millennium issues.
RFC2005 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.
RFC2002 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.
RFC1981 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.
RFC1963 on the PPP Serial Data Transport Protocol defines a flow
expiration time in section 4.9 which has no year 2000 issues.
RFC1833 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.
RFC1762 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.
RFC1761 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.
RFC1755 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.
RFC1692 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.
RFC1661 on PPP defines three timers in Section 4.6, none of which
have any year 2000 issues.
RFC1644 on T/TCP (TCP Extensions for Transactions) mentions RFC1323
and the extended timers recommended in it.
RFC1575 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.
RFC1329 on Dual MAC FDDI Networks discusses ARP cache administration
in Section 9.3 and 9.4 and various timers to expire entries.
RFC1256 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.
RFC792 on ICMP discusses Timestamps and Timestamp Reply messages
which define a 32-bit timestamp which contains the number of
milliseconds since midnight UT.
RFC791 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.
RFC781 was defines the same option which is codified in RFC791 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.
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 RFC1123 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 RFC1123 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.
RFC1153 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.
RFC1327, which describes mapping between X.400 mail and SMTP mail,
uses the UTCTime format.
RFC1422 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.
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.
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 RFC1303. It has persisted unchanged up through
the current specifications in RFC1902. 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 (RFC1559)
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.
16.2.4 Dates in Mobile Network Tracing Records (RFC2041)
The RFCspecifies 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, RFC977, and the Usenet News
Message Format, RFC10336. 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 RFC977. 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 RFC1036. 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
RFC2102 discusses Multicast support for NIMROD and has no mention of
dates or time. RFC2090 on TFTP Multicast options is also free from
any date/time references.
RFC2038 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 RFC2035 on the RTP JPEG format defines the same timestamp
in section 3. RFC2032 on RTP H.261 video streams uses a calculated
time based on the original frame so once again there is no millennium
issue. RFC2029 on the RTP format for Sun"s CellB video encoding
mentions the RTP timestamp in section 2.1.
RFC2022 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.
RFC1890 on RTP profiles for audio and video conferences discusses a
sampling frequency which has no issues. RFC1889 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.
RFC1861 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.
RFC1821 has no date/time references. RFC1819 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.
RFC1645 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.
RFC1458 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. RFC1301 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.
RFC1193 on Client Requirements for Real Time Services talks about
time in section 4.4, but there are no Year 2000 issues. RFC1190
have been obsoleted by RFC1819, 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 RFC1786 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
RFC2091 on Extensions to RIP to Support Demand Circuits defines
three required and one optional timers in section 6. The Database
Timer (6.1), the Hold down Timer (6.2), the Retransmission Time (6.3)
and the Over-Subscription Timer (6.4) are all counters, which have no
millennium, issues. RFC2081 on the applicability of RIPng discusses
deletion of routes for a variety of issues, one of which is the
garbage- collection timer exceeds 120 seconds. There are no Year
2000 issues. RFC2080 on RIPng for IPv6, discusses various times in
section 2.6, none of which have any millennium problems.
RFC1987 on Ipsilon"s General Switch Management protocol there is a
Duration field defined in section 4, which has no relevant problems.
Section 8.2 defines the procedure for dealing with timers. RFC1953
on Ipsilon"s Flow Management Specification for IPv4 defines the same
procedure in section 3.2, as well as a lifetime field in the Redirect
Message (Section 4.1). There are no millennium issues in either
case.
There is a small Year 2000 issue in RFC1786 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.
RFC1771 defines the Border Gateway Protocol (BGP). BGP does not
have knowledge of absolute time, only relative time. There are five
timers defined: Hold Timer, ConnectRetry Timer, KeepAlive Timer,
MinRoueAdvertisementInterval and MinASOriginationInterval. There are
no known issues regarding BGP and the millennium.
In RFC1584, which defines Multicast Extensions to OSPF, three timers
are defined in section 8.2: IGMPPollingInterval, IGMPTimeout, and
IGMP polling timer. Section 8.4 defines an age parameter for the
local groups database and section 9.3 outlines how to implement that
age parameter. It is not expected that any connections lifetime will
be long enough to cause any issues with these timers.
RFC1583, OSPF, there are two types of timers defined in section 4.4,
single-shot timers and interval timers. There are a number of timers
defined in Section 9 including: HelloInterval, RouterDeadInterval,
InfTransDelay, Hello Timer, Wait Timer and RxmtInterval. Section 10
also defines the Inactivity Timer. No millennium problem exists for
any of these timers.
RFC1582 is an earlier version of RFC2091. Section 7 documents the
same timers as noted above, with the same lack of a millennium issue.
RFC1504 on Appletalk Update-Based Routing Protocol defines a 10-
second period in Section 3, and hence has no relevant issues.
RFC1479 which specifies IDPR Version 1, defines a timestamp field in
section 1.5.1, which is a 32 bit unsigned integer number of seconds
since January 1, 1970. The authors recognize the problem of
timestamp exhaustion in 2038, but feel that the protocol will not be
in use for that period. Sections 1.7, 2.1, and 4.3.1 also discuss
the timestamp field. RFC1478 on the IDPR Architecture, also
discusses the same timestamp field in section 3.3.4. RFC1477 again
refers to the IDPR timestamp in section 4.2. Thus IDPR has no Year
2000 issue, but does have a period problem in the year 2038.
RFC1075 on Distance Vector Multicast Routing Protocol devotes
section 7 to time values. None of the timers have any millennium
issues. RFC1074, on the NFSNET backbone SPF IGP defines several
hardcoded timers values in section 5.
RFC1058 on RIP discusses the 30-second timers in section 3.3. There
is no millennium issues related to RIP.
RFC995 on the Requirements for Internet Gateways has extensive
discussions of timers in section 7.1 and throughout A.1 and A.2.
None of these timers suffer from the millennium problem.
RFC911 on EGP on Berkeley Unix recommend timer values of 30 and 120
seconds.
RFC904 which defines the Exterior Gateway Protocol (EGP). There are
a number of timers discussed in sections 4.1.1 and 4.1.4. None of
these timers suffer from any relevant problems.
RFCs 2103, 2092, 2073, 2072, 2042, 2008, 1998, 1997, 1992, 1966, 1955,
1940, 1930, 1925, 1923, 1863, 1817, 1812, 1793, 1787, 1774, 1773,
1772, 1765, 1753, 1745, 1723, 1722, 1721, 1716, 1702, 1701, 1668,
1656, 1655, 1654, 1587, 1586, 1585, 1581, 1520, 1519, 1517, 1482,
1476, 1439, 1403, 1397, 1388, 1387, 1383, 1380, 1371, 1370, 1364,
1338, 1322, 1268, 1267, 1266, 1265, 1264, 1254, 1246, 1245, 1222,
1195, 1164, 1163, 1142, 1136, 1133, 1126, 1125, 1124,1104, 1102, 1092,
1009, 985, 981, 975, 950, 898, 890, 888, 875, and 823 contain no date
or time references.
20. Security
20.1 Summary
The RFC"s which were categorized into this group were kerberos
authentication protocol, Remote Authentication Dial In User Service
(RADIUS), One Time PassWord System (OTP), Privacy Enhanced Mail
(PEM), security extensions to a variety of protocols including (but
not limited to) RIPv2, HTTP, MIME, PPP, IP, Telnet and FTP.
Encryption and authentication algorithms are also examined.
RFC1507 on Distributed Authentication Security Services (DASS)
discusses time and secure time in an expository manner in Sections
1.2.2, 1.4.4 and 2.1. Section 3.6 defines absolute time as an UTC
time with a precision of 1 second, and Section 4.1 discusses ANS.1
encoding of time values. 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 since the year specification only provides
the last two digits of the year.
20.2 Specifics
RFC2082 on RIP-2 MD5 Authentication requires storage of security
keys for a specified lifetime in sections 4.1 and 4.2. There are no
millennium issues in this protocol.
RFC2078 on the GSSAPI Version 2 defines numerous calls that use
timers for inputs and outputs. Sections 2.1.1, 2.1.3, 2.1.4, 2.1.5,
2.2.1, 2.2.2, 2.2.5 and 2.2.6 all use the lifetime_rec field, which
is defined as an integer counter in seconds. There should be no
relevant problems with this protocol.
RFC2069 on Digest Authentication for HTTP, defines a "date" and a
1123 formats which is not subject to millennium issues. Section 3.2
discusses dates and times in the context of thwarting replay attacks,
but have no relevant issues.
RFC2065 on DNS Security extensions first discusses time in section
2.3.3. The SIG RDATA format is defined in Section 4.1 discusses
"time signed" field and defines it to be a 32 bit unsigned integer
number of seconds since January 1, 1970. There will be a period
problem in 2038 because of rollover. Section 4.5 on the file
representations of SIG RRs specifies the time field is expressed as
YYYYMMDDHHMMSS which is clearly Year 2000 compliant.
RFC2059 on RADIUS account formats defines a "time" attribute, which
is optional which is a 32 bit unsigned integer number of seconds
since January 1, 1970. Likewise RFC2058 on RADIUS also defines this
optional attribute in the same way. There will be a potential period
problem that occurs on 2038.
RFC2035 on the Simple Public Key GSSAPI Mechanism talks about secure
timestamps in the background and overview sections only in an
expository manner.
RFC1969 on the PPP DES Encryption Protocol uses time as an example
in Section 4 when discussing how to encrypt the first packet of a
stream. It is suggested that the first 32 bits be used for the
number of seconds since January 1, 1970. There could thus be a
potential operations problem in 2038.
RFC1898 on the CyberCash Credit Card Protocol provides an example
message in Section 2.7 which uses a date field of the form
YYYYMMDDHHMM that is clearly Y2K compliant.
RFC1510, which defines Kerberos Version 5, makes extensive use of
times in the security model. There are discussions in the
Introduction, as well as Sections 1.2, and 3.1.3. Kerberos uses
ASN.1 definitions to abstract values, and hence defines a base
definition for KerberosTime which is a generalized time format in
Section 5.2. >From the text: "Example: The only valid format for UTC
time 6 minutes, 27 seconds after 9 p.m. on 6 November 1985 is
19851106210627Z." A side note is that the MIT reference
implementation of the Kerberos, by default set the expiration of
tickets to December 31, 1999. This is not protocol related but could
have some operational impacts.
RFC1509 on GSSAPI C-bindings makes a single reference that all
counters are in seconds and assigned as 32 bit unsigned integers.
Hence GSSAPI mechanisms may have problems in 2038.
RFC1507 on Distributed Authentication Security Services (DASS)
discusses time and secure time in an expository manner in Sections
1.2.2, 1.4.4 and 2.1. Section 3.6 defines absolute time as an UTC
time with a precision of 1 second, and Section 4.1 discusses ANS.1
encoding of time values. Because of the imprecision of the UTC time
definition there could be problems with this protocol.
RFC1424 on PEM Part IV defines a self-signed certificate request in
Section 3.1. The validity period start and end times are both
suggested to be January 1, 1970. RFC1422 on PEM Part II defines the
validity period for a certificate in Section 3.3.6. It is
recommended that UTC Time formats are used, and notes the lack of a
century so that comparisons between different centuries must be done
with care. No suggestions on how to do this are included. Sections
3.5.2 also discusses validity period in PEM CRLs. RFC1421 on PEM
Part I discusses validity periods in an expository way. PEM as a
whole could have problems after December 31, 1999 based on its use of
UTC Time.
RFCs 1113, 1114, and 1115 specify the original version of PEM and
have been obsoleted bye 1421, 1422, 1423, & 1424.
RFCs 2104, 2085, 2084, 2057, 2040, 2015, 1984, 1968, 1964, 1961, 1949,
1948, 1938, 1929, 1928, 1858, 1852, 1851, 1829, 1828, 1827, 1826,
1825, 1824, 1760, 1751, 1750, 1704, 1675, 1579, 1535, 1511, 1492,
1457, 1455, 1423, 1416, 1412, 1411, 1409, 1408, 1321, 1320, 1319,
1281, 1244, 1186, 1170, 1156, 1108, 1004, 972, 931, 927, 912, and 644
contain no date or time references.
21. Virtual Terminal
21.1 Summary
The RFC"s which were categorized into this group were Telnet and its
many extensions, as well as the Secure SHell (SSH) protocol. The X
window system was not considered since it is not an IETF protocol.
Official acknowledgement by the trustee"s of the X window system was
given that they will examine the protocol.
Unencrypted Telnet and TN3270 have both been found to be Year 2000
Compliant. The SSH protocols are also Year 2000 compliant.
21.2 Specifics
RFC1013 on the X Windows version 11 alpha protocol defines are 32
bit unsigned integer timestamp in Section 4.
RFCs 2066, 1647, 1576, 1572, 1571, 1372, 1282, 1258, 1221, 1205, 1184,
1143, 1116, 1097, 1096, 1091, 1080, 1079, 1073, 1053, 1043, 1041,
1005, 946, 933, 930, 929, 907, 885, 884, 878, 861, 860, 859, 858, 857,
856, 855, 854, 851, 818, 802, 782, 779, 764, 749, 748, 747, 746, 736,
735, 734, 732, 731, 729, 728, 727, 726, 721, 719, 718, 701, 698, 658,
657, 656, 655, 654, 653, 652, 651, 647, 636, 431, 399, 393, 386, 365,
352, 340, 339, 328, 311, 297, 231, and 215 contain no date or time
references.
RFCs 703, 702, 688, 679, 669, 659, 600, 596, 595, 587, 563, 562, 560,
559, 513, 495, 470, 466, 461, 447, 435, 377, 364, 318, 296, 216, 206,
205, 177, 158, 139, 137, 110, 97 were unavailable.
22. Other
22.1 Summary
This grouping was a hodge-podge of informational RFCs, April Fool"s
Jokes, IANA lists, and experimental RFCs. None were found to have
any millennium issues.
22.2 Specifics
RFCs 2123, 2036, 2014, 2000, 1999, 1958, 1935, 1900, 1879, 1855, 1822,
1814, 1810, 1799, 1776, 1718, 1715, 1700, 1699, 1640, 1627, 1610,
1607, 1601, 1600, 1599, 1594, 1580, 1578, 1574, 1550, 1540, 1539,
1527, 1499, 1463, 1462, 1438, 1410, 1402, 1401, 1391, 1367, 1366,
1360, 1359, 1358, 1349, 1340, 1336, 1325, 1324, 1300, 1291, 1287,
1261, 1250, 1249, 1206, 1200, 1199, 1177, 1175, 1174, 1152, 1149,
1140, 1135, 1127, 1118, 1111, 1100, 1099, 1077, 1060, 1039, 1020,
1019, 999, 997, 992, 990, 980, 960, 945, 944, 943, 939, 909, 902, 900,
899, 873, 869, 846, 845, 844, 843, 842, 840, 839, 838, 837, 836, 835,
834, 833, 832, 831, 820, 817, 800, 776, 774, 770, 766, 762, 758, 755,
750, 745, 717, 637, 603, 602, 590, 581, 578, 529, 527, 526, 523, 519,
518, 496, 491, 432, 404, 403, 401, 372, 363, 356, 345, 330, 329, 327,
317, 316, 313, 295, 282, 263, 242, 239, 234, 232, 225, 223, 213, 209,
204, 198, 195, 173, 170, 169, 167, 154, 149, 148, 147, 140, 138, 132,
131, 130, 129, 126, 121, 112, 109, 107, 100, 95, 90, 68, 64, 57, 52,
51, 46, 43, 37, 27, 25, 21, 15, 10, and 9 were examined and none were
found to have any date or time references, let alone millennium or Year
2000 issues.
23. Security Considerations
Although this document does consider the implications of various
security protocols, there is no need for additional security
considerations. The effect of a potential year 2000 problem may
cause some security problems, but those problems are more of specific
applications rather than protocol deficiencies introduced in this
document.
24. References
Because of the exhaustive nature of this investigation, the reader is
referred to the list of published RFC"s available from the IETF
Secretariat or the RFCEditor, rather than republishing them here.
25. Editors" Address
Philip J. Nesser II
Nesser & Nesser Consulting
13501 100th Ave N.E.
Suite 5202
Kirkland, WA 98052
Phone: 425-481-4303
EMail: pjnesser@nesser.com
pjnesser@martigny.ai.mit.edu
Appendix A: List of RFC"s for each Area
The following list contains the RFC"s grouped by area that were
searched for year 2000 problems.
Each line contains three fields are separated by "::". The first
filed is the RFCnumber, the second field is the type of RFC(S =
Standard, DS = Draft Standard, PS = Proposed Standard, E =