RFC relevance of management

As per Relevance of the word management, we have this rfc below:

Network Working Group P. Nesser
Request for Comments: 2626 Nesser & Nesser
Category: Informational June 1999

The Internet and the Millennium Problem (Year 2000)

Status of this

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

Copyright

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

The Year 2000 Working Group (WG) has conducted an investigation
the millennium problem as it regards Internet related protocols
This investigation only targeted the protocols as documented in
Request For Comments Series (RFCs). This investigation
little reason for concern with regards to the functionality of
protocols. A few minor cases of older implementations still
two digit years (ala RFC 850) were discovered, but almost
Internet protocols were given a clean bill of health. Several
of "period" problems were discovered, where a time field would "
over" as the size of field was reached. In particular, there
several protocols, which have 32 bit, signed integer
of the number of seconds since January 1, 1970 which will
negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols
be effected by such problems have been notified so that new
will remove this limitation

1.

According to the trade press billions of dollars will be spend
upcoming years on the year 2000 problem, also called the
problem (though the third millennium will really start in 2001).
problem consists of the fact that many software packages and
protocols use a two-digit field for the year in a date field. Most
the problems seem to be in administrative and financial programs,
in the hardcoded microcomputers found in electronic equipment. A
of organizations are now starting to make an inventory of
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
organizations use the Internet as a serious business tool.
means that most organizations will want to analyze the
problems due to the use of Internet protocols and popular
software. In the trade press the first articles suggest that
Internet will collapse at midnight the 31st of December 1999.

To counter these suggestions, and to avoid having countless
redo the same investigation, this effort was undertaken by the IETF
The Year 2000 WG has made an inventory of all-important
protocols that have been documented in the Request for Comments (RFC
series. Only protocols directly related to the Internet will
considered

This document is divided into a number of sections. Section 1 is
Introduction which you are now reading. Section 2 is a
about the completeness of this effort. Section 3 describes areas
which millenium problems have been found, while Section 4 describes
few other "period" problems. Section 5 describes potential fixes
problems that have been identified. Section 6 describes
methodology used in the investigation. Sections 7 through 22
devoted to the 15 different groupings of protocols and RFCs.
23 discusses security considerations, Section 24 is devoted
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
of problems, and Appendix C is the output of that PERL program

The editor of this document would like to acknowledge the
contributions of the follow for direct performance of research
the provision of text: Alex Latzko, Robert Elz, Erik Huizer,
Greenwood, Barbara Jennings, R.E. (Robert) Moore, David Mills,
Kubinec, Michael Patton, Chris Newman, Erik-Jan Bos, Paul Hoffman
and Rick H. Wesson. The pace with which this group has operated
only been achievable by the intimate familiarity of the
with the protocols and ready access to the collective knowledge
the IETF

2.

This RFC is not complete. It is an effort to analyze the Y2K
on hundreds of protocols but is likely to have missed some
and misunderstood others. Organizations should not attempt to
any legitimacy or approval for any particular protocol based on
document. The efforts have concentrated on the identification
potential problems, rather than solutions to any of the problems
have been identified. Any proposed solutions are only that: proposed
A formal engineering review should take place before any solution

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
any new RFCs to be published that had any Year 2000 issues.
that cutoff time there has been work to correct issues discovered
this Working Group. In particular, RWhois as documented by RFC 1714
has been updated to fix the problems found. RFC 2167 now documents
fixed version of the RWhois protocol. The work of this group was
look backwards, and hence new RFC's which supplant the old
expected to make the information in this RFC obsolete. The work
this group will truly be complete when this document is
obsolete

A number of people have suggested looking into other "special" dates
For example, the first leap year, the first "double digit"
(January 10, 2000), January 1, 2001, etc. There is not one
where days have been used in the protocols defined by the RFC
so there is little reason to believe that any of these special
will have any impact

3. Summary of Year 2000

Here is a brief description of all the Millennium issues
in the course of this research. Note that many of the RFCs
unclear on the issue. They mandate the use of UTCTime but do
specify whether the two-digit or four-digit year
should be used

3.1 "Directory Services

rfc1274.txt - References UTC date/
rfc1276.txt - References UTC date/time for version control
rfc1488.txt - References UTC Time as printable strings
rfc1608.txt - Refers to
rfc1609.txt - Refers to
rfc1778.txt - Refers to

3.2 "Information Services and File Transfer

HTTP 1.1, as defined in RFC 2068, requires all newly generated
stamps to conform to RFC 1123 date formats which are Year 2000
compliant, but it also requires acceptance of the older non-
RFC850 formats. Some specific recommendations have been passed
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
HTML WG

RFC 1778 on String Representations of Standard Attribute Syntax'
define UTC Time in Section 2.21 and uses that definition in
2.25 on User Certificates. Since UTC Time is being used, there is
potential millennium issue

RFC 1440 on SIFT/UFT: Sender-Initiated/Unsolicited File
defines an optional DATE command in Section 5 of the form mm/dd/
which is subject to millennium issues

3.3 "Electronic Mail

After reviewing all mail-related RFCs, it was discovered that
some obsolete standards required two-digit years, all currently
standards require four-digit years and are thus not prone to
Year 2000 problems

RFCs 821 and 822, the main basis for SMTP mail exchange and
format, originally required two-digit years. However, both of
RFCs were later modified by RFC 1123 in 1989, which
recommended 4-digit years

3.4 "Name Serving

While not a protocol issue, there is a common habit of writing
numbers for DNS zone files in the form YYXXXXXX. The only
requirement on the serial numbers is that they be increasing (see
1982 for a complete description) and a change from 99XXXXXX
00XXXXXX cause a failure. See the section on "Name Serving" for
complete description of the issues

3.5 "Network Management

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

3.6 "Network News

There does exist a problem in both NNTP, RFC 977, and the Usenet
Message Format, RFC 10336. They both specify two-digit year format
A working group has been formed to update the network news
in general, and addressing this problem is on their list of
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
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
IP Routing Policies in the ripe-81++ Routing Registry. In
C the "changed" object parameter defines a format of YYMMDD, and similarly in Appendix D "withdrawn" object identifier
he format of YYMMDD. Since these are only identifiers there
be little operational impact. Some application software may need
be modified

3.8 "Security

RFC 1507 on Distributed Authentication Security Services (DASS)
UTCTime. Because of the imprecision of the UTC time definition
could be problems with this protocol

RFCs 1421-1424 specifies that PEM uses UTC time formats which
have a Millennium issue

4. Summary of Other "Periodicity"

By far, the largest area of "period" problems occurs in the
2038. Many protocols use a 32-bit field to record the number
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
the details of rollover can be established

4.2 "Routing

IDPR suffers from the classic Year 2038 problem, by having
timestamp counter which rolls over at that time

5. Suggested

The real solution to the problem is to use 4 digit year fields
applications and hardware systems. For counters that key off of
certain time (January 1, 1970 for example) need to either: define
wrapping solution, or to define a larger number space (greater
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
systems, so solutions for handling problems are in order

5.1 Fixed

A number of organizations and groups have suggested a fixed
to the problem of two digit years. Given a two-digit year YY, if
is greater than or equal to 50, the year shall be interpreted
19YY; and where YY is less than 50, the year shall be intrepreted
20YY

While a simple and straightforward solution, it only pushes
problem off 40 to 50 years, until the artificially generated
2050 problem needs to be addressed. However, it is easy to
and deploy, so it might be the most commonly adopted solution

5.2 Sliding

Another solution is the "sliding window" approach. In this approach
some value N is selected, and any two digit year that is less than
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),
consider it to be in the past(1923-1999, 2000-2011).

This solution has two advantages. First, no new fixed year
are introduced. Second, different applications and protocols
choose different values of N. The drawback is that this solution
harder to implement, and to work well the value of N will need to
constant across different implementations

6.

The first task was dividing the types of RFC's into logical
rather than the strict numeric publishing order. Sixteen
areas were identified. They are: "Autoconfiguration" , "
Services", "Disk Sharing", "Games and Chat" ,"Information Services &
File Transfer", "Network & Transport Layer", "Electronic Mail",
"NTP", Name Serving", "Network Management", "News", "Real
Services", "Routing", "Security", "Virtual Terminal", and "Other".
In addition to these categories, many hundreds of RFC's
immediately eliminated based on content. That is not to say that
Informational RFC's were not considered, many did contain
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
team used whatever additional investigation techniques which
appropriate (including completely reading each RFC, and in some
the source code for the reference implementation) at minimum
team used an automatic scanning system to search for the
items (case insensitively) in each RFC

-
-
-
-
- yy (that is not part of yyyy
- two-digit, 2-digit, 2
-
- 1900 & 2000

Note that all of these strings except "UTCTime" may occur
conjunction with a date format that accommodates the Year 2000
crossing, as well as with one that does not. So "hits" on
string do not necessarily indicate Year 2000 problems: they
identify elements that need to be examined

After the documents were scanned, therefore, each "hit" was
individually. Those that cause no Year 2000 problems (e.g.,
that encode the year as a two-byte integer, or as a four-
display string) are not discussed here. Those that do cause
2000 problems are identified in this document, and the nature
impact of the problems they cause are described

7.

7.1

The RFC's which were categorized into this group were primarily
BOOT Protocol (BOOTP) and the Dynamic Host Configuration
(DHCP) for both IP version four and six

Examination of the BOOTP protocols and most popular
show no year 2000 problems. All times are references as 32
integers in seconds of UTC time. An investigation of all DHCP
the IPv6 Autoconfiguration mechanisms produced no year 2000 problems
All references to time, in particular lease lengths, are 32
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

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
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
these have to do with time. Section 3.4 defines a "Time Offset
field which specifies the offset of the clients subnet in
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
request a specific lease time. This four byte field is an
integer containing a number of seconds. Section 9.9 defines
Renewal Time Value field, Section 9.10 defines a Rebinding
Value, both of which are similarly 32 bit fields, which have
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
of seconds since the host has booted. There is also a discussion
section 3.3 about "Interpretation and Representation of Time Values
which while clearly states that there is no millennium or
problems

RFC 1542 also references the "secs" field mentioned previously

RFC 1970 mentions a number of variables, which are time related.
section 4.2 "Router Advertisement Message Format" the
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 "
Configuration Variables the following are defined: MaxRtrAdvInterval
MinRtrAdvInterval, AdvReachableTime, AdvRetransTimer
AdvDefaultLifetime, AdvValidLifetime, & AdvPreferredLifetime. All
these fields specify counters of some sort which have no
or periodicity problems

RFC 1971 has some discussion of preferred lifetimes,
lifetimes and valid lifetimes of leases, but only discusses them
an expository way

Nesser Informational [Page 8]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

8. Directory

8.1

The RFC's which were categorized into this group were primarily X.500
related RFC's, Whois, Rwhois, Whois++, and the Lightweight
Access Protocol (LDAP).

Upon review of the Directory Services related RFC's, no serious
2000 problems were discovered. Some minor issues were noted
explained below in the specific portion of this section

8.2

RFCs that mentioned UTC Time or made reference to uTCTimeSyntax
fail to be Y2K compliant. These should be updated to specify the
year version of uTCTimeSyntax rather than giving the option of
a two-year date representation. The following RFCs fall into
category

rfc1274.txt - References UTC date/
rfc1276.txt - References UTC date/time for version control
rfc1488.txt - References UTC Time as printable strings
rfc1608.txt - Refers to
rfc1609.txt - Refers to
rfc1778.txt - Refers to

Two RFC's have unusual date specifications and specify their own
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
protocol should only use the %MY4

RFC1834 (Whois++) requires the use of dates, but it didn't
the format, syntax, or representation of the date string to be used

9. Disk

9.1

The RFC's which were categorized into this group were those
to the Network File System (NFS). Other popular disk
protocols like SMB and AFS were referred to their
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

The references to time in this protocol are the times of file
modification, file access, and file metadata change (mtime, atime
and time, respectively). These times are kept as 32 bit
quantities in seconds since 1970-01-01, and so the NFS protocol
not experience an Epoch event until the year 2106.

10. Games and

10.1

The RFC's which were categorized into this group were related to
Internet Relay Chat Protocol (IRC). No millennium problems exist
the IRC protocol

10.2

There is only a single instance of time or date related
in the IRC protocol as specified by RFC 1459. Section 4.3.4
a TIME message type which queries a server for its local time.
mention is made of the format of the reply or how it is parsed,
assumption being specific implementations will handle the reply
parse it appropriately

11. Information Services & File

11.1

The RFC's which were categorized into this group were divided
World Wide Web (WWW) protocols and File Transfer Protocols (FTP).
WWW protocols include the Hypertext Transfer Protocol (HTTP),
variety of Uniform Resource formats (URL, URAs, etc.) and
HyperText Markup Language(HTML). FTP protocols include the
known FTP protocol, the Trivial File Transfer Protocol (TFTP) and
variety of extensions to these protocols. Other information
includes the Finger Protocol and the LPD protocol

HTTP 1.1, as defined in RFC 2068, requires all newly generated
stamps to conform to RFC 1123 date formats which are Year 2000
compliant, but it also requires acceptance of the older non-
RFC850 formats. Some specific recommendations are listed below
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
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'
define UTC Time in Section 2.21 and uses that definition in
2.25 on User Certificates. Since UTC Time is being used, there is
potential millennium issue

RFC 1440 on SIFT/UFT: Sender-Initiated/Unsolicited File
defines an optional DATE command in Section 5 of the form mm/dd/
which is subject to millennium issues

11.2

The main IETF standards-track document on the HTTP protocol
RFC2068 on HTTP 1.1. It notes that historically three different
formats have been used, and that one of them uses a two-digit
field. In section 3.3.1 it requires HTTP 1.1 implementations
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
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
which appears to be more than 50 years in the future is in
in the past (this helps solve the "year 2000" problem).

This avoids a "stale cache" problem, which would cause the user
see out-of-date data

RFC 1986 documents experiments with a simple file transfer
over radio links using Enhanced Trivial FTP (ETFTP). There are
number of timers defined which are all in seconds and have no
2000 issues

In RFC 1866, on HTML 2.0,the tag allows the embedding
recommended values for some HTTP headers, including Expires. E.g

Servers should rewrite these dates into RFC1123 format if necessary

Nesser Informational [Page 11]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

RFC 1807 defines a format for bibliographic records and it
a DATE format, which requires 4 digit year fields

RFC 1788 defines ICMP Domain Name messages. Section 3 defines
Domain Name Reply Packet, which contains a signed 32-bit integer
This timer is not Year 2000 reliant and is certainly large enough
it purposes

RFC 1784 on TFTP Timeout Intervals and Transfer Size Options uses
field for the number of seconds for the timeout. It is an
value from 1 to 255 octets in length. There is no Y2K issue

RFC 1778 on String Representations of Standard Attribute Syntax'
define UTC Time in Section 2.21 and uses that definition in
2.25 on User Certificates. Since UTC Time is being used, there is
potential millennium issue

RFC 1777 on LDAP defines a timelimit in Section 4.3 which
expressed in seconds, but does not define any limits

RFC 1440 on SIFT/UFT: Sender-Initiated/Unsolicited File
defines an optional DATE command in Section 5 of the form mm/dd/yy
which is subject to millennium issues

RFC 1068 on the Background File Transfer Protocol (BFTP) defines
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
protocol will function correctly though the year 9999.

RFC 1037 on NFILE (a file access protocol) discusses the a
representation in Section 7.1 as the number of seconds since
1, 1900, but does not limit the field size. There should be no Y2
issues

RFC 998 on NETBLT defines a Death time in Section 8, which is
sender's death time in seconds

RFC 978 on the Voice File Interchange Protocol defines the Total
of a message to be a 32-bit number of deci-seconds. This limits
size of a message but has no millennium issues

RFC 969 was obsoleted by RFC 998.

RFC 916 defines the Reliable Asynchronous Transfer Protocol (RATP).
Three timers are discussed in an expository manner in Section 5.4
its subsections. There are no relevant issues

Nesser Informational [Page 12]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

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
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
available for review

RFCS below 400 were considered too obsolete to even consider

12. Network & Transport

12.1

The RFC's which were categorized into this group were the
Protocol (IP) versions four and six, the Transmission
Protocol (TCP), the User Datagram Protocol (UDP), the Point-to-
Protocol (PPP) and its extensions, Internet Control Message
(ICMP), the Address Resolution Protocol (ARP) and Remote
Call (RPC) protocol. A variety of less known protocols were
examined

After careful review of the nearly 400 RFC's in this catagory,
millennium or year 2000 problems were found

12.2

RFC 2125 on the PPP Bandwidth Allocation Protocol (BAP) in
5.3 discusses the use if mandatory timers, but gives no mention as
how they are implemented

RFC 2114 on a Data Link Switching Client Access Protocol defines
retry timer of five seconds in Section 3.4.1.

RFC 2097 on the PPP NetBIOS Frame Control Protocol discuesses
timer and timeouts in Section 2.1, none of which suffers from a
2000 problem

RFC 2075 on the IP Echo Host Service discusses timestamps and has
millennium issues

Nesser Informational [Page 13]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

RFC 2005 on the Applicability for Mobile IP discusses
timestamps as a security measure to avoid replay attacks (
3.), but does not quantify them. There are no expected issues

RFC 2002 on IP Mobility Support uses a 16-bit field for the
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
fields, of a similar format to NTP packets

RFC 1981 on Path MTU Discovery for IPv6 discusses timestamps
their potential use to purge stale information in section 5.3.
is no millennium issues in this use

RFC 1963 on the PPP Serial Data Transport Protocol defines a
expiration time in section 4.9 which has no year 2000 issues

RFC 1833 on Binding Protocols for ONC RPC Version 2 defines
variable in Section 2.2.1 called RPCBPROC_GETTIME which returns
local time in seconds since 1/1/1970. Since this value is not
width dependent, it may or may not wrap around the 32-bit
depending on the operating system parameters

RFC 1762 on the PPP DECnet Phase IV Control Protocol discusses
number of timers in Section 5 (General Considerations). None
these timers experience any millennium issues

RFC 1761 on Snoop Version 2 Packet Capture File Format discusses
32-bit timestamp values on Section 4 on Packet Record Formats.
first of these may wrap in the year 2038, but should not
anything of any import

RFC 1755 on ATM Signalling Support for IP Over ATM discusses
issues in Section 3.4 on VC Teardown. These limited timers have
year 2000 issues

RFC 1692 on the Transport Multiplexing Protocol (TMux) defines a
in Section 2.3 and a timer in Section 3.3. Neither of these
from any millennium or year 2000 issues

RFC 1661 on PPP defines three timers in Section 4.6, none of
have any year 2000 issues

RFC 1644 on T/TCP (TCP Extensions for Transactions) mentions RFC 1323
and the extended timers recommended in it

RFC 1575 defines an echo function for CNLP discusses in the
the use of the Lifetime Field in Section 5.3. There is nothing
suggest that there is any year 2000 issues

Nesser Informational [Page 14]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

RFC 1329 on Dual MAC FDDI Networks discusses ARP cache
in Section 9.3 and 9.4 and various timers to expire entries

RFC 1256 on ICMP Router Discovery Messages talks about
fields in Section 2 and defines three router configuration
in Section 4.1. None of these have any millennium issues

RFC 792 on ICMP discusses Timestamps and Timestamp Reply
which define a 32-bit timestamp which contains the number
milliseconds since midnight UT

RFC 791 on the Internet Protocol defines a packet type 68 which is
Internet Timestamp, which defines a 32-bit field which contains
number of milliseconds since midnght UT

RFC 781 was defines the same option which is codified in RFC 791 as
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
millennium references

Nesser Informational [Page 15]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

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
investigation

13. Electronic

13.1

The RFC's which were categorized into this group were the Simple
Transfer Protocol (SMTP), Internet Mail Access Protocol (IMAP),
Office Protocol (POP), Multipurpose Internet Mail Exchange (MIME),
and X.400 to SMTP interaction

After reviewing all mail-related RFCs, it was discovered that
some obsolete standards required two-digit years, all currently
standards require four-digit years and are thus not prone to
Year 2000 problems

13.2

RFCs 821 and 822, the main basis for SMTP mail exchange and
format, originally required two-digit years. However, both of
RFCs were later modified by RFC 1123 in 1989, which
recommended 4-digit years. Although there might be a few very
SMTP systems using two-digit years, it is believed that almost
mail sent over the Internet today uses four-digit years. Mail
contains two-digit years in its SMTP headers will not "fail",
might be mis-sorted in message stores and mail user agents.
problem is avoided entirely by taking the RFC 1123 change as
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
Internet today, but IMAP version 4 has already taken over almost
of the IMAP market. Mail stored on an IMAP server or client
two-digit years will not "fail", but could possibly be mis-sorted
prematurely expired

RFC 1153 describes a format for digests of mailing lists, and
two-digit dates. This format is not widely used. The use of two-
dates could possibly cause missorting of stored messages

Nesser Informational [Page 16]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

RFC 1327, which describes mapping between X.400 mail and SMTP mail
uses the UTCTime format

RFC 1422 describes the structure of certificates that were used
PEM (and are expected to be used in many other mail and non-
services). Those certificates use dates in UTCTime format.
written software might prematurely expire or validate a
based on comparisons of the date with the current date, although
current software is known to do this

14. Network Time

14.1

The RFC's which were categorized into this group were the
Time Protocol (NTP), and the Time Protocol

NTP has been certified year 2000 compliant, while the Time
will "roll over" at Thu Feb 07 00:54:54 2036 GMT. Since NTP is
current defacto standard for network time this does not seem to be
issue

14.2

There is no reference anywhere in the NTP specification
implementation to any reference epoch other than 1 January 1900.
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
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

15.1

The RFC's which were categorized into this group were the Domain
System (DNS), it's advanced add on features (Incremental
Transfer, etc.).

There have been no year 2000 relayed problems found with the
protocols, or common implementations of them

Nesser Informational [Page 17]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

15.2

One is a common practice of writing serial numbers in zone files
if they represent a date, and using only two digits of the year
That practice cannot survive into the year 2000. This is not
protocol problem, the serial number is simply an integer, and
value is OK, provided it always increases (see rfc1982 for
definition of what that means). In any case, a change from 97
(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,
simply to switch, at any time between now and when the serial
first needs updating after the year 2000, to use 4 digits
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
2100, this is always an increase, and therefore always safe.
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
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,
hence have no year 2000 problems. however, they do obviously have
natural end of life, and sometime before that time is reached,
definitions of those fields need to be corrected, perhaps to
them to represent the number of seconds elapsed since the base
modulo 2^32, which is likely to be adequate for the purposes of
security (signatures and keys are unlikely to need to be valid
more than 70 years). In any case, more work is needed in this
in the not too far distant future

16 Network

16.1

The RFC's which were categorized into this group were the
Network Management Protocol (SNMP), a large number of
Information Bases (MIBs) and the Common Management
Protocol over TCP/IP (CMOT).

Although a few discrepancies have been found and outlined below,
of them should have an impact on interoperability

16.2

16.2.1 Use of GeneralizedTime in CMOT as defined in RFCs 1095
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
type. (GeneralizedTime has a four-digit representation of the year.)

If the system generating the PDU does not have the current time,
does have the time since last boot, then GeneralizedTime can be
to encode this information. The time since last boot will be
to the base time "0001 Jan 1 00:00:00.00" using the
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

UTCTime is an ASN.1 type that includes a two-digit representation
the year. There are several options for UTCTime in ASN.1, that
in precision and in local versus GMT, but these options all
two-digit years. The standards for SNMP definitions specify
particular format

The first usage of UTCTime in the standards for SNMP definitions
all the way back to RFC 1303. It has persisted unchanged up
the current specifications in RFC 1902. The role of UTCTime in
definitions is to record the history of an SNMP MIB module in
module itself, via two ASN.1 macros

o LAST-
o

Management applications that store and use MIB modules need to
smart about interpreting these UTCTimes, by prepending a "19" or
"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
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
the objects allow the object value to contain a date, version code
other product specific information to identify the interpreter
language. The descriptions do not include an explicit
recommending use of a four-digit year when a date is used as
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
character arrays of size 32. While 32 characters certainly
enough room for a four-digit year, there's no explicit statement
these years must be represented with four digits

17 Network

17.1

The RFC's which were categorized into this group were related to
Network News Protocol (NNTP).

There does exist a problem in both NNTP, RFC 977, and the Usenet
Message Format, RFC 10336. They both specify two-digit year format
A working group has been formed to update the network news
in general, and addressing this problem is on their list of
items

17.2

The NNTP transfer protocols defined in RFC 977. Sections 3.7.1,
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
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
also mandates the same two-digit year format

18. Real Time

18.1

The RFC's which were categorized into this group were related to
Multicast, RTP, and Internet Stream Protocol. A Year 2000
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

RFC 2102 discusses Multicast support for NIMROD and has no mention
dates or time. RFC 2090 on TFTP Multicast options is also free
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:
Presentation Time Stamp (PTS), a Decoding Time Stamp (DTS), and
System Clock (SC) reference time. Each RTP packet contains
timestamp derived from the sender 90 kHz clock reference. Each
the header fields are defined in section 2.1, 3, and 3.3 are 32
fields. No mention is made of a "zero" start time, so it is
that this format will be valid until at least 2038.

Similarly RFC 2035 on the RTP JPEG format defines the same
in section 3. RFC 2032 on RTP H.261 video streams uses a
time based on the original frame so once again there is no
issue. RFC 2029 on the RTP format for Sun's CellB video
mentions the RTP timestamp in section 2.1.

RFC 2022 defines support for multicast over UNI 3.0/3.1 based
networks. Section 5. defines a timeout value for
between one and twenty minutes. Section 5.1.1 discusses
timers that are bound between five and ten seconds, while 5.1.3
requires an inactivity timer, which should also run between one
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,
of which have any millennium issues

RFC 1890 on RTP profiles for audio and video conferences discusses
sampling frequency which has no issues. RFC 1889 on RTP
time formats in section 4, as the same 64 bit unsigned integer
that NTP uses. There is a "period" problem, which will occur in
year 2106. Section 5.1 is a more formalized discussion of
timestamp properties, while Section 6.3.1 discusses a variety
different timers all using the 64 bit field format, or a
32-bit version of the inner octet of bytes. Section 8.2
loop detection and how the various timers are used to determine
looping occurs

RFC 1861 on Version 3 of the Simple Network Paging Protocol does
a Year 2000 problem. The protocol defines a HOLDuntil command
section 4.5.6 and a MSTAtus command in section 4.6.10, both of
require dates/times to be stored as YYMMDDHHMMSS+/-GMT. Clearly
format will be invalid after the end of 1999.

RFC 1821 has no date/time references. RFC 1819 on Version 2 of
Internet Stream Protocol defines a HELLO message format in
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
the same HOLDuntil field problem as version 3. The definition
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
retransmission timer in section 4.23. and a general discussion
timer expiration in section 5, neither of which have any
concerns. RFC 1301 on the Multicast Transport Protocol defines
heartbeat interval of time in section 2.1, as well as retention
windows. Formal definitions for each are contained in
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
no millennium issues

RFC 1193 on Client Requirements for Real Time Services talks
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
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.

19.1

The RFC's which were categorized into this group were
Information Protocol (RIP), the Open Shortest Path First (OSPF
protocol, Classless InterDomain Routing (CIDR),the Border
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
IP Routing Policies in the ripe-81++ Routing Registry. In
C the "changed" object parameter defines a format of YYMMDD, and similarly in Appendix D "withdrawn" object identifier
he format of YYMMDD. Since these are only identifiers there
be little operational impact. Some application software may need
be modified

IDPR suffers from the classic Year 2038 problem, by having
timestamp counter which rolls over at that time

19.2

RFC 2091 on Extensions to RIP to Support Demand Circuits
three required and one optional timers in section 6. The
Timer (6.1), the Hold down Timer (6.2), the Retransmission Time (6.3)

Nesser Informational [Page 22]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

and the Over-Subscription Timer (6.4) are all counters, which have
millennium, issues. RFC 2081 on the applicability of RIPng
deletion of routes for a variety of issues, one of which is
garbage- collection timer exceeds 120 seconds. There are no
2000 issues. RFC 2080 on RIPng for IPv6, discusses various times
section 2.6, none of which have any millennium problems

RFC 1987 on Ipsilon's General Switch Management protocol there is
Duration field defined in section 4, which has no relevant problems
Section 8.2 defines the procedure for dealing with timers. RFC 1953
on Ipsilon's Flow Management Specification for IPv4 defines the
procedure in section 3.2, as well as a lifetime field in the
Message (Section 4.1). There are no millennium issues in
case

There is a small Year 2000 issue in RFC 1786 on the Representation
IP Routing Policies in the ripe-81++ Routing Registry. In
C the "changed" object parameter defines a format of YYMMDD, and similarly in Appendix D "withdrawn" object identifier
he format of YYMMDD. Since these are only identifiers there
be little operational impact. Some application software may need
be modified

RFC 1771 defines the Border Gateway Protocol (BGP). BGP does
have knowledge of absolute time, only relative time. There are
timers defined: Hold Timer, ConnectRetry Timer, KeepAlive Timer
MinRoueAdvertisementInterval and MinASOriginationInterval. There
no known issues regarding BGP and the millennium

In RFC 1584, which defines Multicast Extensions to OSPF, three
are defined in section 8.2: IGMPPollingInterval, IGMPTimeout,
IGMP polling timer. Section 8.4 defines an age parameter for
local groups database and section 9.3 outlines how to implement
age parameter. It is not expected that any connections lifetime
be long enough to cause any issues with these timers

RFC 1583, OSPF, there are two types of timers defined in section 4.4,
single-shot timers and interval timers. There are a number of
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
any of these timers

RFC 1582 is an earlier version of RFC 2091. Section 7 documents
same timers as noted above, with the same lack of a millennium issue

RFC 1504 on Appletalk Update-Based Routing Protocol defines a 10-
second period in Section 3, and hence has no relevant issues

Nesser Informational [Page 23]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

RFC 1479 which specifies IDPR Version 1, defines a timestamp field
section 1.5.1, which is a 32 bit unsigned integer number of
since January 1, 1970. The authors recognize the problem
timestamp exhaustion in 2038, but feel that the protocol will not
in use for that period. Sections 1.7, 2.1, and 4.3.1 also
the timestamp field. RFC 1478 on the IDPR Architecture,
discusses the same timestamp field in section 3.3.4. RFC 1477
refers to the IDPR timestamp in section 4.2. Thus IDPR has no
2000 issue, but does have a period problem in the year 2038.

RFC 1075 on Distance Vector Multicast Routing Protocol
section 7 to time values. None of the timers have any
issues. RFC 1074, on the NFSNET backbone SPF IGP defines
hardcoded timers values in section 5.

RFC 1058 on RIP discusses the 30-second timers in section 3.3.
is no millennium issues related to RIP

RFC 995 on the Requirements for Internet Gateways has
discussions of timers in section 7.1 and throughout A.1 and A.2.
None of these timers suffer from the millennium problem

RFC 911 on EGP on Berkeley Unix recommend timer values of 30 and 120
seconds

RFC 904 which defines the Exterior Gateway Protocol (EGP). There
a number of timers discussed in sections 4.1.1 and 4.1.4. None
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
or time references

20.

20.1

The RFC's which were categorized into this group were
authentication protocol, Remote Authentication Dial In User
(RADIUS), One Time Password System (OTP), Privacy Enhanced
(PEM), security extensions to a variety of protocols including (
not limited to) RIPv2, HTTP, MIME, PPP, IP, Telnet and FTP

Nesser Informational [Page 24]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

Encryption and authentication algorithms are also examined

RFC 1507 on Distributed Authentication Security Services (DASS
discusses time and secure time in an expository manner in
1.2.2, 1.4.4 and 2.1. Section 3.6 defines absolute time as an
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
definition there could be problems with this protocol

RFCs 1421-1424 specifies that PEM uses UTC time formats which
have a Millennium issue since the year specification only
the last two digits of the year

20.2

RFC 2082 on RIP-2 MD5 Authentication requires storage of
keys for a specified lifetime in sections 4.1 and 4.2. There are
millennium issues in this protocol

RFC 2078 on the GSSAPI Version 2 defines numerous calls that
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,
is defined as an integer counter in seconds. There should be
relevant problems with this protocol

RFC 2069 on Digest Authentication for HTTP, defines a 'date' and
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

RFC 2065 on DNS Security extensions first discusses time in
2.3.3. The SIG RDATA format is defined in Section 4.1
"time signed" field and defines it to be a 32 bit unsigned
number of seconds since January 1, 1970. There will be a
problem in 2038 because of rollover. Section 4.5 on the
representations of SIG RRs specifies the time field is expressed
YYYYMMDDHHMMSS which is clearly Year 2000 compliant

RFC 2059 on RADIUS account formats defines a "time" attribute,
is optional which is a 32 bit unsigned integer number of
since January 1, 1970. Likewise RFC 2058 on RADIUS also defines
optional attribute in the same way. There will be a potential
problem that occurs on 2038.

RFC 2035 on the Simple Public Key GSSAPI Mechanism talks about
timestamps in the background and overview sections only in
expository manner

Nesser Informational [Page 25]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

RFC 1969 on the PPP DES Encryption Protocol uses time as an
in Section 4 when discussing how to encrypt the first packet of
stream. It is suggested that the first 32 bits be used for
number of seconds since January 1, 1970. There could thus be
potential operations problem in 2038.

RFC 1898 on the CyberCash Credit Card Protocol provides an
message in Section 2.7 which uses a date field of the
YYYYMMDDHHMM that is clearly Y2K compliant

RFC 1510, which defines Kerberos Version 5, makes extensive use
times in the security model. There are discussions in
Introduction, as well as Sections 1.2, and 3.1.3. Kerberos
ASN.1 definitions to abstract values, and hence defines a
definition for KerberosTime which is a generalized time format
Section 5.2. >From the text: "Example: The only valid format for
time 6 minutes, 27 seconds after 9 p.m. on 6 November 1985
19851106210627Z." A side note is that the MIT
implementation of the Kerberos, by default set the expiration
tickets to December 31, 1999. This is not protocol related but
have some operational impacts

RFC 1509 on GSSAPI C-bindings makes a single reference that
counters are in seconds and assigned as 32 bit unsigned integers
Hence GSSAPI mechanisms may have problems in 2038.

RFC 1507 on Distributed Authentication Security Services (DASS
discusses time and secure time in an expository manner in
1.2.2, 1.4.4 and 2.1. Section 3.6 defines absolute time as an
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
definition there could be problems with this protocol

RFC 1424 on PEM Part IV defines a self-signed certificate request
Section 3.1. The validity period start and end times are
suggested to be January 1, 1970. RFC 1422 on PEM Part II defines
validity period for a certificate in Section 3.3.6. It
recommended that UTC Time formats are used, and notes the lack of
century so that comparisons between different centuries must be
with care. No suggestions on how to do this are included.
3.5.2 also discusses validity period in PEM CRLs. RFC 1421 on
Part I discusses validity periods in an expository way. PEM as
whole could have problems after December 31, 1999 based on its use
UTC Time

RFCs 1113, 1114, and 1115 specify the original version of PEM
have been obsoleted bye 1421, 1422, 1423, & 1424.

Nesser Informational [Page 26]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

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

21.1

The RFC's which were categorized into this group were Telnet and
many extensions, as well as the Secure SHell (SSH) protocol. The
window system was not considered since it is not an IETF protocol
Official acknowledgement by the trustee's of the X window system
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

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

22.1

This grouping was a hodge-podge of informational RFCs, April Fool'
Jokes, IANA lists, and experimental RFCs. None were found to
any millennium issues

Nesser Informational [Page 27]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

22.2

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
found to have any date or time references, let alone millennium or
2000 issues

23. Security

Although this document does consider the implications of
security protocols, there is no need for additional
considerations. The effect of a potential year 2000 problem
cause some security problems, but those problems are more of
applications rather than protocol deficiencies introduced in
document

24.

Because of the exhaustive nature of this investigation, the reader
referred to the list of published RFC's available from the
Secretariat or the RFC Editor, rather than republishing them here

25. Editors'

Philip J. Nesser
Nesser & Nesser
13501 100th Ave N.E
Suite 5202
Kirkland, WA 98052

Phone: 425-481-4303
EMail: pjnesser@nesser.
pjnesser@martigny.ai.mit.

Nesser Informational [Page 28]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

Appendix A: List of RFC's for each

The following list contains the RFC's grouped by area that
searched for year 2000 problems

Each line contains three fields are separated by '::'. The
filed is the RFC number, the second field is the type of RFC (S =
Standard, DS = Draft Standard, PS = Proposed Standard, E =
Experimental, H = Historical, I = Informational, BC = Best
Practice, '' = No Type), and the third field is the Title

A.1

1971:: PS:: IPv6 Stateless Address
1970:: PS:: Neighbor Discovery for IP Version 6 (IPv6)
1542:: PS:: Clarifications and Extensions for the Bootstrap
1541:: PS:: Dynamic Host Configuration
1534:: PS:: Interoperation Between DHCP and
1533:: PS:: DHCP Options and BOOTP Vendor
1532:: PS:: Clarifications and Extensions for the Bootstrap
1531:: PS:: Dynamic Host Configuration
1497:: DS:: BOOTP Vendor Information
1395:: DS:: BOOTP Vendor Information
1084:: DS:: BOOTP vendor information
1048:: DS:: BOOTP vendor information
951:: DS:: Bootstrap
906:: :: Bootstrap loading using

A.2 Directory

2120:: E :: Managing the X.500 Root Naming
2079:: PS:: Definition of X.500 Attribute Types and an Object
to Hold Uniform Resource Identifiers (URIs
1943:: I:: Building an X.500 Directory Service in the
1914:: PS:: How to interact with a Whois++
1913:: PS:: Architecture of the Whois++ Index
1838:: E:: Use of the X.500 Directory to support mapping
X.400 and RFC 822
1837:: E:: Representing Tables and Subtrees in the X.500
1836:: E:: Representing the O/R Address hierarchy in the X.500
Directory Information
1835:: PS:: Architecture of the WHOIS++
1834:: I:: Whois and Network Information Lookup Service Whois++
1781:: PS:: Using the OSI Directory to Achieve User Friendly
1714:: I:: Referral Whois Protocol (RWhois
1684:: I:: Introduction to White Pages services based on X.500
1637:: E:: DNS NSAP Resource
1632:: I:: A Revised Catalog of Available X.500

Nesser Informational [Page 29]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

1617:: I:: Naming and Structuring Guidelines for X.500 Directory
1609:: E:: Charting Networks in the X.500
1608:: E:: Representing IP Information in the X.500
1588:: I:: WHITE PAGES MEETING
1562:: I:: Naming Guidelines for the AARNet X.500 Directory
1491:: I:: A Survey of Advanced Usages of X.500
1488:: PS:: The X.500 String Representation of Standard

1487:: PS:: X.500 Lightweight Directory Access
1485:: PS:: A String Representation of Distinguished
1484:: E:: Using the OSI Directory to achieve User Friendly
1430:: I:: A Strategic Plan for Deploying an Internet X.500
Directory
1400:: I:: Transition and Modernization of the Internet

1384:: I:: Naming Guidelines for Directory
1355:: I:: Privacy and Accuracy Issues in Network
Center
1330:: I:: Recommendations for the Phase I Deployment of
Directory Services (X.500) and OSI Message
Services (X.400) within the ESnet
1309:: I:: Technical Overview of Directory Services Using
X.500
1308:: I:: Executive Introduction to Directory Services Using
X.500
1292:: I:: A Catalog of Available X.500
1279:: :: X.500 and
1276:: PS:: Replication and Distributed Operations extensions
provide an Internet Directory using X.500
1275:: I:: Replication Requirements to provide an Internet
using X.500
1274:: PS:: The COSINE and Internet X.500
1255:: I:: A Naming Scheme for c=
1218:: :: A Naming Scheme for c=
1202:: I:: Directory Assistance
1107:: :: Plan for Internet directory
954:: DS:: NICNAME/
953:: H:: Hostname
812:: :: NICNAME/
756:: :: NIC name server - a datagram-based information
752:: :: Universal host
============ ==========================================================
Disk
1813:: I:: NFS Version 3 Protocol
1094:: H:: NFS: Network File System Protocol
============ ==========================================================
Games and
1459:: E:: Internet Relay Chat

Nesser Informational [Page 30]

RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999

======================================================================
Information Services & File
2122:: PS:: VEMMI URL
2070:: PS:: Internationalization of the Hypertext Markup
2068:: PS:: Hypertext Transfer Protocol -- HTTP/1.1
2056:: PS:: Uniform Resource Locators for Z39.50
2055:: I:: WebNFS Server
2054:: I:: WebNFS Client
2044:: I:: UTF-8, a transformation format of Unicode and ISO 10646
2016:: E:: Uniform Resource Agents (URAs
1986:: E:: Experiments with a Simple File Transfer Protocol
Radio Links using Enhanced Trivial File
Protocol (ETFTP
1980:: I:: A Proposed Extension to HTML: Client-Side Image
1960:: PS:: A String Representation of LDAP Search <