draft-ietf-v6ops-ipv4survey-sec-00.txt   draft-ietf-v6ops-ipv4survey-sec-01.txt 
Network Working Group Philip J. Nesser II Network Working Group Philip J. Nesser II
draft-ietf-v6ops-ipv4survey-sec-00.txt Nesser & Nesser Consulting draft-ietf-v6ops-ipv4survey-sec-01.txt Nesser & Nesser Consulting
Expires August 2003 Internet Draft Andreas Bergstrom
Ostfold University College
June 2003
Expires December 2003
Survey of IPv4 Addresses in Currently Deployed Survey of IPv4 Addresses in Currently Deployed
IETF Security Area Standards IETF Security Area Standards
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Status of this Memo Status of this Memo
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at line 32 skipping to change at line 35
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document seeks to document all usage of IPv4 addresses in currently This document seeks to document all usage of IPv4 addresses in currently
deployed IETF Security Area documented standards. In order to deployed IETF Security Area documented standards. In order to
successfully transition from an all IPv4 Internet to an all IPv6 Internet, successfully transition from an all IPv4 Internet to an all IPv6
many interim steps will be taken. One of these steps is the evolution of Internet, many interim steps will be taken. One of these steps is the
current protocols that have IPv4 dependencies. It is hoped that these evolution of current protocols that have IPv4 dependencies. It is hoped
protocols (and their implementations) will be redesigned to be network that these protocols (and their implementations) will be redesigned to
address independent, but failing that will at least dually support IPv4 be network address independent, but failing that will at least dually
and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well support IPv4 and IPv6. To this end, all Standards (Full, Draft, and
as Experimental RFCs will be surveyed and any dependencies will be documented. Proposed) as well as Experimental RFCs will be surveyed and any
dependencies will be documented.
1.0 Introduction
This work began as a megolithic document draft-ietf-ngtrans-
ipv4survey-XX.txt. In an effort to rework the information into a more
manageable form, it has been broken into 8 documents conforming to the
current IETF areas (Application, General, Internet, Manangement & Operations,
Routing, Security, Sub-IP and Transport).
1.1 Short Historical Perspective
There are many challenges that face the Internet Engineering community.
The foremost of these challenges has been the scaling issue. How to grow
a network that was envisioned to handle thousands of hosts to one that
will handle tens of millions of networks with billions of hosts. Over the
years this scaling problem has been overcome with changes to the network
layer and to routing protocols. (Ignoring the tremendous advances in
computational hardware)
The first "modern" transition to the network layer occurred in during the
early 1980's from the Network Control Protocol (NCP) to IPv4. This
culminated in the famous "flag day" of January 1, 1983. This version of
IP was documented in RFC 760. This was a version of IP with 8 bit network
and 24 bit host addresses. A year later IP was updated in RFC 791 to
include the famous A, B, C, D, & E class system.
Networks were growing in such a way that it was clear that a need for
breaking networks into smaller pieces was needed. In October of 1984 RFC
917 was published formalizing the practice of subnetting.
By the late 1980's it was clear that the current exterior routing protocol
used by the Internet (EGP) was not sufficient to scale with the growth of
the Internet. The first version of BGP was documented in 1989 in RFC
1105.
The next scaling issues to became apparent in the early 1990's was the
exhaustion of the Class B address space. The growth and commercialization
of the Internet had organizations requesting IP addresses in alarming
numbers. In May of 1992 over 45% of the Class B space was allocated. In
early 1993 RFC 1466 was published directing assignment of blocks of Class
C's be given out instead of Class B's. This solved the problem of address
space exhaustion but had significant impact of the routing infrastructure.
The number of entries in the "core" routing tables began to grow
exponentially as a result of RFC 1466. This led to the implementation of
BGP4 and CIDR prefix addressing. This may have solved the problem for the
present but there are still potential scaling issues.
Current Internet growth would have long overwhelmed the current address
space if industry didn't supply a solution in Network Address Translators
(NATs). To do this the Internet has sacrificed the underlying
"End-to-End" principle.
In the early 1990's the IETF was aware of these potential problems and
began a long design process to create a successor to IPv4 that would
address these issues. The outcome of that process was IPv6.
The purpose of this document is not to discuss the merits or problems of
IPv6. That is a debate that is still ongoing and will eventually be
decided on how well the IETF defines transition mechanisms and how
industry accepts the solution. The question is not "should," but "when."
1.2 A Brief Aside
Throughout this document there are discussions on how protocols might be
updated to support IPv6 addresses. Although current thinking is that IPv6
should suffice as the dominant network layer protocol for the lifetime of
the author, it is not unreasonable to contemplate further upgrade to IP.
Work done by the IRTF Interplanetary Internet Working Group shows one idea
of far reaching thinking. It may be a reasonable idea (or may not) to
consider designing protocols in such a way that they can be either IP
version aware or independent. This idea must be balanced against issues
of simplicity and performance. Therefore it is recommended that protocol
designer keep this issue in mind in future designs.
Just as a reminder, remember the words of Jon Postel:
"Be conservative in what you send; be liberal in what
you accept from others."
2.0 Methodology
To perform this study each class of IETF standards are investigated in Table of Contents
order of maturity: Full, Draft, and Proposed, as well as Experimental.
Informational RFC are not addressed. RFCs that have been obsoleted by
either newer versions or as they have transitioned through the standards
process are not covered.
Please note that a side effect of this choice of methodology is that 1. Introduction
some protocols that are defined by a series of RFC's that are of different 2. Document Organisation
levels of standards maturity are covered in different spots in the 3. Full Standards
document. Likewise other natural groupings (i.e. MIBs, SMTP extensions, 4. Draft Standards
IP over FOO, PPP, DNS, etc.) could easily be imagined. 5. Proposed Standards
6. Experimental RFCs
7. Summary of Results
7.1 Standards
7.2 Draft Standards
7.3 Proposed Standards
7.4 Experimental RFCs
8. Security Consideration
9. Acknowledgements
10. References
11. Authors Address
12. Intellectual Property Statement
13. Full Copyright Statement
2.1 Scope 1.0 Introduction
The procedure used in this investigation is an exhaustive reading of the This document is part of a document set aiming to document all usage of
applicable RFC's. This task involves reading approximately 25000 pages IPv4 addresses in IETF stanadards. In an effort to have the information
of protocol specifications. To compound this, it was more than a process in a manageable form, it has been broken into 7 documents conforming
of simple reading. It was necessary to attempt to understand the purpose to the current IETF areas (Application, Internet, Manangement &
and functionality of each protocol in order to make a proper determination Operations, Routing, Security, Sub-IP and Transport).
of IPv4 reliability. The author has made ever effort to make this effort
and the resulting document as complete as possible, but it is likely that
some subtle (or perhaps not so subtle) dependence was missed. The author
encourage those familiar (designers, implementers or anyone who has an
intimate knowledge) with any protocol to review the appropriate sections
and make comments.
2.2 Document Organization For a full introduction, please see the intro[1] draft.
The rest of the document sections are described below. 2.0 Document Organization
Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft,
and Proposed Standards, and Experimental RFCs. Each RFC is discussed in and Proposed Standards, and Experimental RFCs. Each RFC is discussed
its turn starting with RFC 1 and ending with RFC 3247. The comments for in its turn starting with RFC 1 and ending with RFC 3247. The comments
each RFC is "raw" in nature. That is, each RFC is discussed in a vacuum for each RFC is "raw" in nature. That is, each RFC is discussed in a
and problems or issues discussed do not "look ahead" to see if the vacuum and problems or issues discussed do not "look ahead" to see if
problems have already been fixed. the problems have already been fixed.
Section 7 is an analysis of the data presented in Sections 3, 4, 5, and Section 7 is an analysis of the data presented in Sections 3, 4, 5, and
6. It is here that all of the results are considered as a whole and the 6. It is here that all of the results are considered as a whole and the
problems that have been resolved in later RFCs are correlated. problems that have been resolved in later RFCs are correlated.
3.0 Full Standards 3.0 Full Standards
Full Internet Standards (most commonly simply referred to as "Standards") Full Internet Standards (most commonly simply referred to as
are fully mature protocol specification that are widely implemented and "Standards") are fully mature protocol specification that are widely
used throughout the Internet. implemented and used throughout the Internet.
3.1 RFC 2289 A One-Time Password System (ONE-PASS) 3.1 RFC 2289 A One-Time Password System (ONE-PASS)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
4.0 Draft Standards 4.0 Draft Standards
Draft Standards represent the penultimate standard level in the IETF. Draft Standards represent the penultimate standard level in the IETF.
A protocol can only achieve draft standard when there are multiple, A protocol can only achieve draft standard when there are multiple,
independent, interoperable implementations. Draft Standards are usually independent, interoperable implementations. Draft Standards are usually
skipping to change at line 214 skipping to change at line 139
request is coming from a false IP address and must cause the server request is coming from a false IP address and must cause the server
to deliver the document to an IP address different from the address to deliver the document to an IP address different from the address
to which it believes it is sending the document. An attack can only to which it believes it is sending the document. An attack can only
succeed in the period before the time-stamp expires. Digesting the succeed in the period before the time-stamp expires. Digesting the
client IP and time-stamp in the nonce permits an implementation which client IP and time-stamp in the nonce permits an implementation which
does not maintain state between transactions. does not maintain state between transactions.
Both of these statements are IP version independent and once again must Both of these statements are IP version independent and once again must
rely on the implementers discretion. rely on the implementers discretion.
4.3 RFC 2865 Remote Authentication Dial In User Service (RADIUS) (RADIUS) 4.3 RFC 2865 Remote Authentication Dial In User Service (RADIUS)
Section 3. Packet Format has the following notes: Section 3. Packet Format has the following notes:
Identifier Identifier
The Identifier field is one octet, and aids in matching requests The Identifier field is one octet, and aids in matching requests
and replies. The RADIUS server can detect a duplicate request if and replies. The RADIUS server can detect a duplicate request if
it has the same client source IP address and source UDP port and it has the same client source IP address and source UDP port and
Identifier within a short span of time. Identifier within a short span of time.
skipping to change at line 364 skipping to change at line 289
Address Address
The Address field is four octets specifying the IP netmask of the The Address field is four octets specifying the IP netmask of the
user. user.
5.14. Login-IP-Host 5.14. Login-IP-Host
Description Description
This Attribute indicates the system with which to connect the user, "This Attribute indicates the system with which to connect the user,
when the Login-Service Attribute is included. It MAY be used in when the Login-Service Attribute is included. It MAY be used in
Access-Accept packets. It MAY be used in an Access-Request packet as Access-Accept packets. It MAY be used in an Access-Request packet as
a hint to the server that the NAS would prefer to use that host, but a hint to the server that the NAS would prefer to use that host, but
the server is not required to honor the hint. the server is not required to honor the hint."
A summary of the Login-IP-Host Attribute format is shown below. The A summary of the Login-IP-Host Attribute format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address | Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) | Address (cont) |
skipping to change at line 454 skipping to change at line 379
Although the definitions in this RFC are limited to IPv4 addresses, Although the definitions in this RFC are limited to IPv4 addresses,
the protocol is easily extensible for new attribute types. It is the protocol is easily extensible for new attribute types. It is
therefore relatively simple to create new IPv6 specific attributes. therefore relatively simple to create new IPv6 specific attributes.
5.0 Proposed Standards 5.0 Proposed Standards
Proposed Standards are introductory level documents. There are no Proposed Standards are introductory level documents. There are no
requirements for even a single implementation. In many cases Proposed requirements for even a single implementation. In many cases Proposed
are never implemented or advanced in the IETF standards process. They are never implemented or advanced in the IETF standards process. They
therefore are often just proposed ideas that are presented to the Internet therefore are often just proposed ideas that are presented to the
community. Sometimes flaws are exposed or they are one of many competing Internet community. Sometimes flaws are exposed or they are one of many
solutions to problems. In these later cases, no discussion is presented competing solutions to problems. In these later cases, no discussion is
as it would not serve the purpose of this discussion. presented as it would not serve the purpose of this discussion.
5.001 RFC 1413 Identification Protocol (IDENT) 5.001 RFC 1413 Identification Protocol (IDENT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.002 RFC 1421 Privacy Enhancement for Internet Electronic Mail: 5.002 RFC 1421 Privacy Enhancement for Internet Electronic Mail:
Part I (PEM-ENC) Part I (PEM-ENC)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
skipping to change at line 750 skipping to change at line 675
of (a) domain name widget.foo.example, (b) IPv4 address of (a) domain name widget.foo.example, (b) IPv4 address
10.251.13.201, and (c) string "James Hacker 10.251.13.201, and (c) string "James Hacker
<hacker@mail.widget.foo.example>". Then the storage locations <hacker@mail.widget.foo.example>". Then the storage locations
recommended, in priority order, would be recommended, in priority order, would be
(1) widget.foo.example, (1) widget.foo.example,
(2) 201.13.251.10.in-addr.arpa, and (2) 201.13.251.10.in-addr.arpa, and
(3) hacker.mail.widget.foo.example. (3) hacker.mail.widget.foo.example.
Since the definition of X.509v3 certificates is not discussed in this Since the definition of X.509v3 certificates is not discussed in this
document it is unclear if IPv6 addresses are also supported in the document it is unclear if IPv6 addresses are also supported in the
above mentioned field. above mentioned field. The document does however refer to RFC 2459
for the definition of a certificate, and RFC 2459 is IPv6 and IPv4
aware.
5.055 RFC 2539 Storage of Diffie-Hellman Keys in the Domain Name 5.055 RFC 2539 Storage of Diffie-Hellman Keys in the Domain Name
System (DNS) (DHK-DNS) System (DNS) (DHK-DNS)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.056 RFC 2559 Internet X.509 Public Key Infrastructure Operational 5.056 RFC 2559 Internet X.509 Public Key Infrastructure Operational
Protocols - LDAPv2 Protocols - LDAPv2
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
skipping to change at line 810 skipping to change at line 737
5.066 RFC 2661 Layer Two Tunneling Protocol "L2TP" (L2TP) 5.066 RFC 2661 Layer Two Tunneling Protocol "L2TP" (L2TP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.067 RFC 2712 Addition of Kerberos Cipher Suites to Transport Layer 5.067 RFC 2712 Addition of Kerberos Cipher Suites to Transport Layer
Security (TLS) (TLS) Security (TLS) (TLS)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.068 RFC 2725 Routing Policy System Security 5.068 RFC 2743 Generic Security Service Application Program Interface
There are no IPv4 dependencies in this protocol.
5.069 RFC 2726 PGP Authentication for RIPE Database Updates
There are no IPv4 dependencies in this protocol.
5.070 RFC 2743 Generic Security Service Application Program Interface
Version 2 Update 1 Version 2 Update 1
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.071 RFC 2744 Generic Security Service API Version 2 : C-bindings 5.069 RFC 2744 Generic Security Service API Version 2 : C-bindings
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.072 RFC 2747 RSVP Cryptographic Authentication 5.070 RFC 2747 RSVP Cryptographic Authentication
This protocol is both IPv4 and IPv6 aware and needs no changes. This protocol is both IPv4 and IPv6 aware and needs no changes.
5.073 RFC 2797 Certificate Management Messages over CMS 5.071 RFC 2797 Certificate Management Messages over CMS
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.074 RFC 2829 Authentication Methods for LDAP 5.072 RFC 2829 Authentication Methods for LDAP
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.075 RFC 2830 Lightweight Directory Access Protocol (v3): 5.073 RFC 2830 Lightweight Directory Access Protocol (v3):
Extension for Transport Layer Security (LDAP) Extension for Transport Layer Security (LDAP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.076 RFC 2831 Using Digest Authentication as a SASL Mechanism 5.074 RFC 2831 Using Digest Authentication as a SASL Mechanism
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.077 RFC 2845 Secret Key Transaction Authentication for DNS (TSIG) 5.075 RFC 2845 Secret Key Transaction Authentication for DNS (TSIG)
(TSIG) (TSIG)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.078 RFC 2847 LIPKEY - A Low Infrastructure Public Key Mechanism 5.076 RFC 2847 LIPKEY - A Low Infrastructure Public Key Mechanism
Using SPKM (LIPKEY) Using SPKM (LIPKEY)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.079 RFC 2853 Generic Security Service API Version 2 : Java 5.077 RFC 2853 Generic Security Service API Version 2 : Java
Bindings Bindings
The document uses the InetAddress variable which does not The document uses the InetAddress variable which does not
necessarily limit it to IPv4 addresses so there are no IPv4 necessarily limit it to IPv4 addresses so there are no IPv4
dependencies in this protocol. dependencies in this protocol.
5.080 RFC 2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH 5.078 RFC 2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.081 RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms 5.079 RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.082 RFC 2930 Secret Key Establishment for DNS (TKEY RR) 5.080 RFC 2930 Secret Key Establishment for DNS (TKEY RR)
(TKEY-RR) (TKEY-RR)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.083 RFC 2931 DNS Request and Transaction Signatures 5.081 RFC 2931 DNS Request and Transaction Signatures
(SIG(0)s) (SIG(0)s)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.084 RFC 2935 Internet Open Trading Protocol (IOTP) HTTP 5.082 RFC 2935 Internet Open Trading Protocol (IOTP) HTTP
Supplement (IOTP-HTTP) Supplement (IOTP-HTTP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.085 RFC 2941 Telnet Authentication Option (TOPT-AUTH) 5.083 RFC 2941 Telnet Authentication Option (TOPT-AUTH)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.086 RFC 2942 Telnet Authentication: Kerberos Version 5 5.084 RFC 2942 Telnet Authentication: Kerberos Version 5
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.087 RFC 2943 TELNET Authentication Using DSA 5.085 RFC 2943 TELNET Authentication Using DSA
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.088 RFC 2944 Telnet Authentication: SRP 5.086 RFC 2944 Telnet Authentication: SRP
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.089 RFC 2945 The SRP Authentication and Key Exchange 5.087 RFC 2945 The SRP Authentication and Key Exchange
System System
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.090 RFC 2946 Telnet Data Encryption Option 5.088 RFC 2946 Telnet Data Encryption Option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.091 RFC 2947 Telnet Encryption: DES3 64 bit Cipher 5.089 RFC 2947 Telnet Encryption: DES3 64 bit Cipher
Feedback Feedback
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.092 RFC 2948 Telnet Encryption: DES3 64 bit Output 5.090 RFC 2948 Telnet Encryption: DES3 64 bit Output
Feedback Feedback
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.093 RFC 2949 Telnet Encryption: CAST-128 64 bit Output 5.091 RFC 2949 Telnet Encryption: CAST-128 64 bit Output
Feedback Feedback
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.094 RFC 2950 Telnet Encryption: CAST-128 64 bit Cipher 5.092 RFC 2950 Telnet Encryption: CAST-128 64 bit Cipher
Feedback Feedback
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.095 RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS 5.093 RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.096 RFC 3007 Secure Domain Name System (DNS) Dynamic Update 5.094 RFC 3007 Secure Domain Name System (DNS) Dynamic Update
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.097 RFC 3008 Domain Name System Security (DNSSEC) Signing 5.095 RFC 3008 Domain Name System Security (DNSSEC) Signing
Authority (DNSSEC) Authority (DNSSEC)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.098 RFC 3012 Mobile IPv4 Challenge/Response Extensions 5.096 RFC 3012 Mobile IPv4 Challenge/Response Extensions
This document is specifically designed for IPv4. This document is specifically designed for IPv4.
5.099 RFC 3039 Internet X.509 Public Key Infrastructure Qualified 5.097 RFC 3039 Internet X.509 Public Key Infrastructure Qualified
Certificates Profile Certificates Profile
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.100 RFC 3041 Privacy Extensions for Stateless Address 5.098 RFC 3041 Privacy Extensions for Stateless Address
Autoconfiguration in IPv6 Autoconfiguration in IPv6
This is an IPv6 related document and is not discussed in this This is an IPv6 related document and is not discussed in this
document. document.
5.101 RFC 3062 LDAP Password Modify Extended Operation 5.099 RFC 3062 LDAP Password Modify Extended Operation
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.102 RFC 3070 Layer Two Tunneling Protocol (L2TP) over 5.100 RFC 3070 Layer Two Tunneling Protocol (L2TP) over
Frame Relay (L2TP-FR) Frame Relay (L2TP-FR)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.103 RFC 3075 XML-Signature Syntax and Processing 5.101 RFC 3075 XML-Signature Syntax and Processing
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.104 RFC 3090 DNS Security Extension Clarification on Zone Status 5.102 RFC 3090 DNS Security Extension Clarification on Zone Status
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.105 RFC 3097 RSVP Cryptographic Authentication -- Updated Message 5.103 RFC 3097 RSVP Cryptographic Authentication -- Updated Message
Type Value (RSVP) Type Value (RSVP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.106 RFC 3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 5.104 RFC 3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
System (DNS) System (DNS)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.107 RFC 3118 Authentication for DHCP Messages 5.105 RFC 3118 Authentication for DHCP Messages
This document is only designated for IPv4. It is expected that This document is only designated for IPv4. It is expected that
similar functionality is available in DHCPv6. similar functionality is available in DHCPv6.
6.0 Experimental RFCs 6.0 Experimental RFCs
Experimental RFCs typically define protocols that do not have widescale Experimental RFCs typically define protocols that do not have widescale
implementation or usage on the Internet. They are often propriety in implementation or usage on the Internet. They are often propriety in
nature or used in limited arenas. They are documented to the Internet nature or used in limited arenas. They are documented to the Internet
community in order to allow potential interoperability or some other community in order to allow potential interoperability or some other
skipping to change at line 1129 skipping to change at line 1048
This protocol is both IPv4 and IPv6 aware and needs no changes. This protocol is both IPv4 and IPv6 aware and needs no changes.
6.18 RFC 3029 Internet X.509 Public Key Infrastructure Data 6.18 RFC 3029 Internet X.509 Public Key Infrastructure Data
Validation and Certification Server Protocols Validation and Certification Server Protocols
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
7.0 Summary of Results 7.0 Summary of Results
In the initial survey of RFCs 6 positives were identified out of a In the initial survey of RFCs 6 positives were identified out of a
total of 129, broken down as follows: total of 127, broken down as follows:
Standards 0 of 1 or 0.00% Standards 0 of 1 or 0.00%
Draft Standards 1 of 3 or 33.33% Draft Standards 1 of 3 or 33.33%
Proposed Standards 4 of 107 or 3.74% Proposed Standards 4 of 105 or 3.81%
Experimental RFCs 1 of 18 or 5.56% Experimental RFCs 1 of 18 or 5.56%
Of those identified many require no action because they document Of those identified many require no action because they document
outdated and unused protocols, while others are document protocols outdated and unused protocols, while others are document protocols
that are actively being updated by the appropriate working groups. that are actively being updated by the appropriate working groups.
Additionally there are many instances of standards that SHOULD be Additionally there are many instances of standards that SHOULD be
updated but do not cause any operational impact if they are not updated but do not cause any operational impact if they are not
updated. The remaining instances are documented below. updated. The remaining instances are documented below.
The author has attempted to organize the results in a format that allows
easy reference to other protocol designers. The following recommendations
uses the documented terms "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
described in RFC 2119. They should only be interpreted in the context
of RFC 2119 when they appear in all caps. That is, the word "should" in
the previous SHOULD NOT be interpreted as in RFC 2119.
The assignment of these terms has been based entirely on the authors
perceived needs for updates and should not be taken as an official
statement.
7.1 Standards 7.1 Standards
7.2 Draft Standards 7.2 Draft Standards
7.2.1 RADIUS (RFC 2865) 7.2.1 RADIUS (RFC 2865)
The problems have been resolved in RFC 3162, RADIUS and IPv6. The problems have been resolved in RFC 3162, RADIUS and IPv6.
7.3 Proposed Standards 7.3 Proposed Standards
7.3.1 RIPv2 MD5 Authentication (RFC 2082) 7.3.1 RIPv2 MD5 Authentication (RFC 2082)
This functionality has been assumed by the use of the IPsec AH This functionality has been assumed by the use of the IPsec AH
header as defined in RFC 1826, IP Authentication Header. header as defined in RFC 2402, IP Authentication Header.
7.3.2 Protection of BGP via TCP MD5 Signatures (RFC 2385) 7.3.2 Protection of BGP via TCP MD5 Signatures (RFC 2385)
These issues are addressed via using BGP4 plus RFC 2283, These issues are addressed via using BGP4 plus RFC 2283,
Multiprotocol Extensions for BGP-4. Multiprotocol Extensions for BGP-4.
7.3.3 Mobile IPv4 Challenge Response Extension (RFC 3012) 7.3.3 Mobile IPv4 Challenge Response Extension (RFC 3012)
The problems are not being addressed and MUST be addressed in a new The problems are not being addressed and must be addressed in a new
protocol. protocol.
7.3.4 Authentication for DHCP Messages (RFC 3118) 7.3.4 Authentication for DHCP Messages (RFC 3118)
The problem is being fixed by the work of the DHC WG. Several very The problem is being fixed by the work of the DHC WG. Several very
advanced IDs address all the issues. advanced IDs address all the issues.
7.4 Experimental RFCs 7.4 Experimental RFCs
7.4.1 Scalable Multicast Key Distribution (RFC 1949) 7.4.1 Scalable Multicast Key Distribution (RFC 1949)
This protocol relies on IPv4 IGMP Multicast and a new protocol This protocol relies on IPv4 IGMP Multicast and a new protocol
standard MAY be produced. standard may be produced.
8.0 Acknowledgements 8.0 Security Consideration
The author would like to acknowledge the support of the Internet Society This memo examines the IPv6-readiness of specifications; this does not
in the research and production of this document. Additionally the have security considerations in itself.
author would like to thanks his partner in all ways, Wendy M. Nesser.
9.0 Authors Address 9.0 Acknowledgements
The authors would like to acknowledge the support of the Internet
Society in the research and production of this document.
Additionally the author, Philip J. Nesser II, would like to thanks
his partner in all ways, Wendy M. Nesser.
The editor, Andreas Bergstrom, would like to thank Pekka Savola
for guidance and collection of comments for the editing of this
document.
10.0 References
10.1 Normative
[1] Philip J. Nesser II, Andreas Bergstrom. "Introduction to the Survey of
IPv4 Addresses in Currently Deployed IETF Standards",
draft-ietf-v6ops-ipv4survey-intro-01.txt IETF work in progress,
June 2003
11.0 Authors Addresses
Please contact the author with any questions, comments or suggestions Please contact the author with any questions, comments or suggestions
at: at:
Philip J. Nesser II Philip J. Nesser II
Principal Principal
Nesser & Nesser Consulting Nesser & Nesser Consulting
13501 100th Ave NE, #5202 13501 100th Ave NE, #5202
Kirkland, WA 98034 Kirkland, WA 98034
Email: phil@nesser.com Email: phil@nesser.com
Phone: +1 425 481 4303 Phone: +1 425 481 4303
Fax: +1 425 48 Fax: +1 425 48
Andreas Bergstrom
Ostfold University College
Email: andreas.bergstrom@hiof.no
Address: Rute 503 Buer
N-1766 Halden
Norway
12.0 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
13.0 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this docu-
ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English. The lim-
ited permissions granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns. This document
and the information contained herein is provided on an "AS IS" basis
and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS-
CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/