draft-ietf-v6ops-ipv4survey-intro-06.txt   rfc3789.txt 
Network Working Group Philip J. Nesser II
draft-ietf-v6ops-ipv4survey-intro-06.txt Nesser & Nesser Consulting Network Working Group P. Nesser, II
Internet Draft Andreas Bergstrom (Ed.) Request for Comments: 3789 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College Ostfold University College
December 2003 June 2004
Expires May 2004
Introduction to the Survey of IPv4 Addresses in Introduction to the Survey of IPv4 Addresses in
Currently Deployed IETF Standards Currently Deployed IETF Standards Track and Experimental Documents
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2004).
http://www.ietf.org/shadow.html.
Abstract Abstract
This document is a general overview and introduction to the v6ops IETF This document is a general overview and introduction to the v6ops
workgroup project of documenting all usage of IPv4 addresses in IETF workgroup project of documenting all usage of IPv4 addresses in
currently deployed IETF documented standards. It is broken into seven IETF standards track and experimental RFCs. It is broken into seven
documents conforming to the current IETF areas. It also describes the documents conforming to the current IETF areas. It also describes
methodology used during documentation, which type of RFCs that has the methodology used during documentation, which types of RFCs have
been documented, and a concatenated summary of results. been documented, and provides a concatenated summary of results.
Table of Contents Table of Contents
1. Introduction 1.0. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Short Historical Perspective 1.1. Short Historical Perspective . . . . . . . . . . . . . 2
1.2 An Observation on the Classification of Standards 1.2. An Observation on the Classification of Standards. . . 3
2. Methodology 2.0. Methodology. . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Scope 2.1. Scope. . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Summary of Results 3.0. Summary of Results . . . . . . . . . . . . . . . . . . . . . 5
3.1 Application Area Specifications 3.1. Application Area Specifications. . . . . . . . . . . . 5
3.2 Internet Area Specifications 3.2. Internet Area Specifications . . . . . . . . . . . . . 5
3.3 Operations & Management Area Specifications 3.3. Operations and Management Area Specifications. . . . . 6
3.4 Routing Area Specifications 3.4. Routing Area Specifications. . . . . . . . . . . . . . 6
3.5 Security Area Specifications 3.5. Security Area Specifications . . . . . . . . . . . . . 6
3.6 Sub-IP Area Specifications 3.6. Sub-IP Area Specifications . . . . . . . . . . . . . . 6
3.7 Transport Area Specifications 3.7. Transport Area Specifications. . . . . . . . . . . . . 7
4. Discussion of "Long Term" Stability of Addresses on Protocols 4.0. Discussion of "Long Term" Stability of Addresses on
5. Security Consideration Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements 5.0. Security Considerations. . . . . . . . . . . . . . . . . . . 8
7. References 6.0. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7.1 Normative 7.0. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Authors' Addresses 7.1. Normative References . . . . . . . . . . . . . . . . . 8
9. Intellectual Property Statement 8.0. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
10. Full Copyright Statement 9.0. Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
1.0 Introduction 1.0. Introduction
This document is the introduction to a document set aiming to This document is the introduction to a document set aiming to
document all usage of IPv4 addresses in IETF standards. In an effort to document all usage of IPv4 addresses in IETF standards. In an effort
have the information in a manageable form, it has been broken into 7 to have the information in a manageable form, it has been broken into
documents conforming to the current IETF areas (Application[1], 7 documents, conforming to the current IETF areas (Application [1],
Internet[2], Management & Operations[3], Routing[4], Security[5], Internet [2], Operations and Management [3], Routing [4], Security
Sub-IP[6] and Transport[7]). It also describes the methodology used [5], Sub-IP [6], and Transport [7]). It also describes the
during documentation, which type of RFCs that has been documented, methodology used during documentation, which types of RFCs that have
and a concatenated summary of results. been documented, and provides a concatenated summary of results.
1.1 Short Historical Perspective 1.1. Short Historical Perspective
There are many challenges that face the Internet Engineering community. There are many challenges that face the Internet Engineering
The foremost of these challenges has been the scaling issue: how to community. The foremost of these challenges has been the scaling
grow a network that was envisioned to handle thousands of hosts to one issue: how to grow a network that was envisioned to handle thousands
that will handle tens of millions of networks with billions of hosts. of hosts to one that will handle tens of millions of networks with
Over the years this scaling problem has been managed, with varying billions of hosts. Over the years, this scaling problem has been
degrees of succes, by changes to the network layer and to routing managed, with varying degrees of success, by changes to the network
protocols. (Although largely ignored in the changes to network layer layer and to routing protocols. (Although largely ignored in the
and routing protocols, the tremendous advances in computational changes to network layer and routing protocols, the tremendous
hardware during the past two decades have been of significant benefit advances in computational hardware during the past two decades have
in managment of scaling problems encountered thus far.) been of significant benefit in management of scaling problems
encountered thus far.)
The first "modern" transition to the network layer occurred in during The first "modern" transition to the network layer occurred during
the early 1980's from the Network Control Protocol (NCP) to IPv4. This the early 1980's, moving from the Network Control Protocol (NCP) to
culminated in the famous "flag day" of January 1, 1983. IP Version 4 IPv4. This culminated in the famous "flag day" of January 1, 1983.
originally specified an 8 bit network and 24 bit host addresses, as IP Version 4 originally specified an 8 bit network and 24 bit host
documented in RFC 760. A year later IPv4 was updated in RFC 791 to addresses, as documented in RFC 760. A year later, IPv4 was updated
include the famous A, B, C, D, & E class system. in RFC 791 to include the famous A, B, C, D, and E class system.
Networks were growing in such a way that it was clear that a convention Networks were growing in such a way that it was clear that a
for breaking networks into smaller pieces was needed. In October of convention for breaking networks into smaller pieces was needed. In
1984 RFC 917 was published formalizing the practice of subnetting. 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 By the late 1980's, it was clear that the current exterior routing
protocol used by the Internet (EGP) was insufficiently robust to scale protocol used by the Internet (EGP) was insufficiently robust to
with the growth of the Internet. The first version of BGP was scale with the growth of the Internet. The first version of BGP was
documented in 1989 in RFC 1105. documented in 1989 in RFC 1105.
Yet another scaling issue, exhaustion of the class B address space, Yet another scaling issue, exhaustion of the class B address space
became apparent in the early 1990s. The growth and commercialization became apparent in the early 1990s. The growth and commercialization
of the Internet stimulated organisations requesting IP addresses in of the Internet stimulated organisations requesting IP addresses in
alarming numbers. By May of 1992 over 45% of the Class B space had alarming numbers. By May of 1992, over 45% of the Class B space had
been allocated. In early 1993 RFC 1466 was published directing been allocated. In early 1993 RFC 1466 was published, directing
assignment of blocks of Class C's be given out instead of Class B's. assignment of blocks of Class C's be given out instead of Class B's.
This temporarily circumvented the problem of address space exhaustion, This temporarily circumvented the problem of address space
but had significant impact of the routing infrastructure. exhaustion, but had a significant impact of the routing
infrastructure.
The number of entries in the "core" routing tables began to grow The number of entries in the "core" routing tables began to grow
exponentially as a result of RFC 1466. This led to the implementation exponentially as a result of RFC 1466. This led to the
of BGP4 and CIDR prefix addressing. This may have circumvented the implementation of BGP4 and CIDR prefix addressing. This may have
problem for the present but there are still potential scaling issues. circumvented the problem for the present, but they continue to pose
potential scaling issues.
Growth in the population of Internet hosts since the mid-1980s would Growth in the population of Internet hosts since the mid-1980s would
have long overwhelmed the IPv4 address space if industry had not have long overwhelmed the IPv4 address space if industry had not
supplied a circumvention in the form of Network Address Translators supplied a circumvention in the form of Network Address Translators
(NATs). To do this the Internet has watered down the underlying (NATs). To do this, the Internet has watered down the underlying
"End-to-End" principle. "End-to-End" principle.
In the early 1990's the IETF was aware of these potential problems and In the early 1990's, the IETF was aware of these potential problems
began a long design process to create a successor to IPv4 that would and began a long design process to create a successor to IPv4 that
address these issues. The outcome of that process was IPv6. 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 The purpose of this document is not to discuss the merits or problems
IPv6. That is a debate that is still ongoing and will eventually be of IPv6. That debate is still ongoing and will eventually be decided
decided on how well the IETF defines transition mechanisms and how on how well the IETF defines transition mechanisms and how industry
industry accepts the solution. The question is not "should," but accepts the solution. The question is not "should," but "when."
"when."
1.2 An Observation on the Classification of Standards 1.2. An Observation on the Classification of Standards
It has become clear during the course of this investigation that there It has become clear during the course of this investigation that
has been little management of the status of standards over the years. there has been little management of the status of standards over the
Some attempt has been made by the introduction of the classification of years. Some attempt has been made by the introduction of the
standards into Full, Draft, Proposed, Experimental, and Historic. classification of standards into Full, Draft, Proposed, Experimental,
However, there has not been a concerted effort to actively manage the and Historic. However, there has not been a concerted effort to
classification for older standards. Standards are only classified as actively manage the classification for older standards. Standards
Historic when either a newer version of the protocol is deployed, are only classified as Historic when either a newer version of the
it is randomly noticed that an RFC describes a long dead protocol, or protocol is deployed and it is randomly noticed that an RFC describes
a serious flaw is discovered in a protocol. Another issue is the status a long dead protocol, or a serious flaw is discovered in a protocol.
of Proposed Standards. Since this is the entry level position for Another issue is the status of Proposed Standards. Since this is the
protocols entering the standards process, many old protocols or non- entry level position for protocols entering the standards process,
implemented protocols linger in this status indefinitely. This problem many old protocols or non-implemented protocols linger in this status
also exists for Experimental RFCs. Similarly the problem exists indefinitely. This problem also exists for Experimental RFCs.
for the Best Current Practices (BCP) and For You Information (FYI) Similarly, the problem exists for the Best Current Practices (BCP)
series of documents. and For You Information (FYI) series of documents.
To exemplify this point, there are 61 Full Standards, only 4 of which To exemplify this point, there are 61 Full Standards, only 4 of which
have been reclassified to Historic. There are 65 Draft Standards, 611 have been reclassified to Historic. There are 65 Draft Standards,
Proposed Standards, and 150 Experimental RFCs, of which only 66 611 Proposed Standards, and 150 Experimental RFCs, of which only 66
have been reclassified as Historic. That is a rate of less than 8%. have been reclassified as Historic. That is a rate of less than 8%.
It should be obvious that in the more that 30 years of protocol It should be obvious that in the more that 30 years of protocol
development and documentation there should be at least as many (if development and documentation, there should be at least as many (if
not a majority of) protocols that have been retired compared to the ones not a majority of) protocols that have been retired compared to the
that are currently active. ones that are currently active.
Please note that there is occasionally some confusion of the meaning of Please note that there is occasionally some confusion of the meaning
a "Historic" classification. It does NOT necessarily mean that the of a "Historic" classification. It does NOT necessarily mean that
protocol is not being used. A good example of this concept is the the protocol is not being used. A good example of this concept is
Routing Information Protocol(RIP) version 1. There are many thousands the Routing Information Protocol(RIP) version 1. There are many
of sites using this protocol even though it has Historic status. There thousands of sites using this protocol even though it has Historic
are potentially hundreds of otherwise classified RFC's that should be status. There are potentially hundreds of otherwise classified RFC's
reclassified. that should be reclassified.
2.0 Methodology 2.0. Methodology
To perform this study each class of IETF standards are investigated in To perform this study, each class of IETF standards are investigated
order of maturity: Full, Draft, and Proposed, as well as Experimental. in order of maturity: Full, Draft, and Proposed, as well as
Informational and BCP RFCs are not addressed. RFCs that have been Experimental. Informational and BCP RFCs are not addressed. RFCs
obsoleted by either newer versions or as they have transitioned through that have been obsoleted by either newer versions or because they
the standards process are not covered. RFCs which have been classified have transitioned through the standards process are not covered.
as Historic are also not included. RFCs which have been classified as Historic are also not included.
Please note that a side effect of this choice of methodology is that Please note that a side effect of this choice of methodology is that
some protocols that are defined by a series of RFC's that are of some protocols that are defined by a series of RFC's that are of
different levels of standards maturity are covered in different spots different levels of standards maturity are covered in different spots
in the document. Likewise other natural groupings (i.e. MIBs, SMTP in the document. Likewise, other natural groupings (i.e., MIBs, SMTP
extensions, IP over FOO, PPP, DNS, etc.) could easily be imagined. extensions, IP over FOO, PPP, DNS, etc.) could easily be imagined.
2.1 Scope 2.1. Scope
The procedure used in this investigation is an exhaustive reading of the The procedure used in this investigation is an exhaustive reading of
applicable RFC's. This task involves reading approximately 25000 pages the applicable RFC's. This task involves reading approximately
of protocol specifications. To compound this, it was more than a 25,000 pages of protocol specifications. To compound this, it was
process of simple reading. It was necessary to attempt to understand more than a process of simple reading. It was necessary to attempt
the purpose and functionality of each protocol in order to make a proper to understand the purpose and functionality of each protocol in order
determination of IPv4 reliability. The author has made every effort to to make a proper determination of IPv4 reliability. The author has
make this effort and the resulting document as complete as possible, but made every effort to produce as complete a document set as possible,
it is likely that some subtle (or perhaps not so subtle) dependence was but it is likely that some subtle (or perhaps not so subtle)
missed. The author encourage those familiar (designers, implementers dependence was missed. The author encourages those familiar
or anyone who has an intimate knowledge) with any protocol to review (designers, implementers or anyone who has an intimate knowledge)
the appropriate sections and make comments. with any protocol to review the appropriate sections and make
comments.
3.0 Summary of Results 3.0. Summary of Results
In the initial survey of RFCs 175 positives were identified, out of a In the initial survey of RFCs, 173 positives were identified out of a
total of 871, broken down as follows: total of 877, broken down as follows:
Standards 32 of 65 or 49.23% Standards: 30 out of 68 or 44.12%
Draft Standards 14 of 59 or 23.73% Draft Standards: 16 out of 68 or 23.53%
Proposed Standards 107 of 602 or 17.77% Proposed Standards: 98 out of 597 or 16.42%
Experimental RFCs 22 of 145 or 15.17% Experimental RFCs: 29 out of 144 or 20.14%
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 active document
that are actively being updated by the appropriate working groups protocols being updated by the appropriate working groups (SNMP MIBs
(SNMP MIBs for example). for example).
Additionally there are many instances of standards that should be
updated but do not cause any operational impact (STD 3/RFCs 1122 & 1123 Additionally, there are many instances of standards that should be
for example) if they are not updated. updated but do not cause any operational impact (STD 3/RFCs 1122 and
1123 for example) if they are not updated.
In this statistical survey, a positive is defined as a RFC containing In this statistical survey, a positive is defined as a RFC containing
an IPv4 dependency, regardless of context. an IPv4 dependency, regardless of context.
3.1 Application Area Specifications 3.1. Application Area Specifications
In the initial survey of RFCs, 33 positives were identified out of a In the initial survey of RFCs, 34 positives were identified out of a
total of 257, broken down as follows: total of 257, broken down as follows:
Standards: 1 out of 20, or 5.00% Standards: 1 out of 20 or 5.00%
Draft Standards: 4 out of 25, or 16.00% Draft Standards: 4 out of 25 or 16.00%
Proposed Standards: 19 out of 155 or 12.26% Proposed Standards: 19 out of 155 or 12.26%
Experimental RFCs: 10 out of 57 or 17.54% Experimental RFCs: 10 out of 57 or 17.54%
For more information, please look at [1]. For more information, please look at [1].
3.2 Internet Area Specifications 3.2. Internet Area Specifications
In the initial survey of RFCs 52 positives were identified out of a In the initial survey of RFCs, 52 positives were identified out of a
total of 186, broken down as follows: total of 186, broken down as follows:
Standards 17 of 24 or 70.83% Standards: 17 out of 24 or 70.83%
Draft Standards 6 of 20 or 30.00% Draft Standards: 6 out of 20 or 30.00%
Proposed Standards 22 of 111 or 19.91% Proposed Standards: 22 out of 111 or 19.91%
Experimental RFCs 7 of 31 or 22.58% Experimental RFCs: 7 out of 31 or 22.58%
For more information, please look at [2]. For more information, please look at [2].
3.3 Operations & Management Area Specifications 3.3. Operations and Management Area Specifications
In the initial survey of RFCs 36 positives were identified out of a In the initial survey of RFCs, 36 positives were identified out of a
total of 153, broken down as follows: total of 153, broken down as follows:
Standards 6 of 15 or 40.00% Standards: 6 out of 15 or 40.00%
Draft Standards 4 of 15 or 26.67% Draft Standards: 4 out of 15 or 26.67%
Proposed Standards 26 of 112 or 23.21% Proposed Standards: 26 out of 112 or 23.21%
Experimental RFCs 0 of 11 or 0.00% Experimental RFCs: 0 out of 11 or 0.00%
For more information, please look at [3]. For more information, please look at [3].
3.4 Routing Area Specifications 3.4. Routing Area Specifications
In the initial survey of RFCs, 22 positives were identified out of a In the initial survey of RFCs, 23 positives were identified out of a
total of 44, broken down as follows: total of 46, broken down as follows:
Standards 3 of 3 or 100.00% Standards: 3 out of 3 or 100.00%
Draft Standards 1 of 2 or 50.00% Draft Standards: 1 out of 3 or 33.33%
Proposed Standards 13 of 29 or 44.83% Proposed Standards: 13 out of 29 or 44.83%
Experimental RFCs 6 of 11 or 54.54% Experimental RFCs: 6 out of 11 or 54.54%
For more information, please look at [4]. For more information, please look at [4].
3.5 Security Area Specifications 3.5. Security Area Specifications
In the initial survey of RFCs 4 positives were identified out of a In the initial survey of RFCs, 4 positives were identified out of a
total of 124, broken down as follows: total of 124, broken down as follows:
Standards 0 of 1 or 0.00% Standards: 0 out of 1 or 0.00%
Draft Standards 1 of 3 or 33.33% Draft Standards: 1 out of 3 or 33.33%
Proposed Standards 1 of 102 or 0.98% Proposed Standards: 1 out of 102 or 0.98%
Experimental RFCs 2 of 18 or 11.11% Experimental RFCs: 2 out of 18 or 11.11%
For more information, please look at [5]. For more information, please look at [5].
3.6 Sub-IP Area Specifications 3.6. Sub-IP Area Specifications
In the initial survey of RFCs, 0 positives were identified out of a In the initial survey of RFCs, 0 positives were identified out of a
total of 7, broken down as follows: total of 7, broken down as follows:
Standards 0 of 0 or 0.00% Standards: 0 out of 0 or 0.00%
Draft Standards 0 of 0 or 0.00% Draft Standards: 0 out of 0 or 0.00%
Proposed Standards 0 of 6 or 0.00% Proposed Standards: 0 out of 6 or 0.00%
Experimental RFCs 0 of 1 or 0.00% Experimental RFCs: 0 out of 1 or 0.00%
For information about the Sub-IP Area standards, please look at [6]. For information about the Sub-IP Area standards, please look at [6].
3.7 Transport Area Specifications 3.7. Transport Area Specifications
In the initial survey of RFCs 25 positives were identified out of a In the initial survey of RFCs, 24 positives were identified out of a
total of 104, broken down as follows: total of 104, broken down as follows:
Standards 3 of 5 or 60.00% Standards: 3 out of 5 or 60.00%
Draft Standards 0 of 2 or 0.00% Draft Standards: 0 out of 2 or 0.00%
Proposed Standards 17 of 82 or 20.73% Proposed Standards: 17 out of 82 or 20.73%
Experimental RFCs 4 of 15 or 26.67% Experimental RFCs: 4 out of 15 or 26.67%
For more information, please look at [7]. For more information, please look at [7].
4.0 Discussion of "Long Term" Stability of Addresses on Protocols 4.0. Discussion of "Long Term" Stability of Addresses on Protocols
In attempting this analysis it was determined that a full scale In attempting this analysis, it was determined that a full scale
analysis is well beyond the scope of this document. Instead a short analysis is well beyond the scope of this document. Instead, a short
discussion is presented on how such a framework might be established. discussion is presented on how such a framework might be established.
A suggested approach would be to do an analysis of protocols based on A suggested approach would be to do an analysis of protocols based on
their overall function, similar (but not strictly) to the OSI network their overall function, similar (but not strictly) to the OSI network
reference model. It might be more appropriate to frame the discussion reference model. It might be more appropriate to frame the
in terms of the different Areas of the IETF. discussion in terms of the different Areas of the IETF.
The problem is fundamental to the overall architecture of the Internet The problem is fundamental to the overall architecture of the
and its future. One of the stated goals of the IPng (now IPv6) was Internet and its future. One of the stated goals of the IPng (now
"automatic" and "easy" address renumbering. An additional goal is IPv6) was "automatic" and "easy" address renumbering. An additional
"stateless autoconfiguration." To these ends, a substantial amount of goal is "stateless autoconfiguration." To these ends, a substantial
work has gone into the development of such protocols as DHCP and Dynamic amount of work has gone into the development of such protocols as
DNS. This goes against the Internet age-old "end-to-end principle." DHCP and Dynamic DNS. This goes against the Internet age-old "end-
to-end principle."
Most protocol designs implicitly count on certain underlying principles Most protocol designs implicitly count on certain underlying
that currently exist in the network. For example, the design of packet principles that currently exist in the network. For example, the
switched networks allows upper level protocols to ignore the underlying design of packet switched networks allows upper level protocols to
stability of packet routes. When paths change in the network, the ignore the underlying stability of packet routes. When paths change
higher level protocols are typically unaware and uncaring. This works in the network, the higher level protocols are typically unaware and
well since whether the packet goes A-B-C-D-E-F or A-B-X-Y-Z-E-F is of uncaring. This works well since whether the packet goes A-B-C-D-E-F
little consequence. or A-B-X-Y-Z-E-F is of little consequence.
In a world where endpoints (i.e. A and F in the example above) change In a world where endpoints (i.e., A and F in the example above)
at a "rapid" rate, a new model for protocol developers should be change at a "rapid" rate, a new model for protocol developers should
considered. It seems that a logical development would be a change in be considered. It seems that a logical development would be a change
the operation of the Transport layer protocols. The current model is in the operation of the Transport layer protocols. The current model
essentially a choice between TCP and UDP, Neither of these protocols is essentially a choice between TCP and UDP, neither of which
provides any mechanism for an orderly handoff of the connection if and provides any mechanism for an orderly handoff of the connection if
when the network endpoint (IP) addresses changes. Perhaps a third and when the network endpoint (IP) addresses change. Perhaps a third
major transport layer protocol should be developed, or perhaps updated major transport layer protocol should be developed, or perhaps
TCP & UDP specifications that include this function might be a better updated TCP and UDP specifications that include this function might
solution. be a better solution.
There are many, many variables that would need to go into a successful There are many, many variables that would need to go into a
development of such a protocol. Some issues to consider are: timing successful development of such a protocol. Some issues to consider
principles; overlap periods as an endpoint moves from address A, to are: timing principles; overlap periods as an endpoint moves from
addresses A & B (answers to both), to only B; delays due to the address A, to addresses A and B (answers to both), to only B; delays
recalculation of routing paths, etc... due to the recalculation of routing paths, etc...
5.0 Security Consideration 5.0. Security Considerations
This memo examines the IPv6-readiness of specifications; this does not This memo examines the IPv6-readiness of specifications; this does
have security considerations in itself. not have security considerations in itself.
6.0 Acknowledgements 6.0. Acknowledgements
The authors would like to acknowledge the support of the Internet The authors would like to acknowledge the support of the Internet
Society in the research and production of this document. Society in the research and production of this document.
Additionally the author, Philip J. Nesser II, would like to thanks Additionally the author, Philip J. Nesser II, would like to thanks
his partner in all ways, Wendy M. Nesser. his partner in all ways, Wendy M. Nesser.
The editor, Andreas Bergstrom, would like to thank Pekka Savola The editor, Andreas Bergstrom, would like to thank Pekka Savola for
for guidance and collection of comments for the editing of this guidance and collection of comments for the editing of this document.
He would further like to thank Alan E. Beard, Jim Bound, Brian
Carpenter, and Itojun for valuable feedback on many points of this
document. document.
He would further like to thank Alan E. Beard, Jim Bound, Brian Carpenter
and Itojun for valuable feedback on many points of this document.
7.0 References 7.0. References
7.1 Normative 7.1. Normative References
[1] Philip J. Nesser II, Rute Sofia. "Survey of IPv4 Addresses [1] Sofia, R. and P. Nesser, II, "Survey of IPv4 Addresses in
in Currently Deployed IETF Application Area Standards", Currently Deployed IETF Application Area Standards", RFC 3795,
draft-ietf-v6ops-ipv4survey-apps-03.txt June 2004.
IETF work in progress, October 2003
[2] Philip J. Nesser II, Cleveland Mickles. "Internet Area: Survey [2] Mickles, C., Editor and P. Nesser, II, "Survey of IPv4 Addresses
of IPv4 Addresses Currently Deployed Deployed IETF Standards", in Currently Deployed IETF Internet Area Standards", RFC 3790,
draft-ietf-v6ops-ipv4survey-int-02.txt June 2004.
IETF work in progress, October 2003
[3] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses [3] Nesser, II, P. and A. Bergstrom, Editor, "Survey of IPv4
in Currently Deployed IETF Operations & Management Area Standards", Addresses in Currently Deployed IETF Operations & Management
draft-ietf-v6ops-ipv4survey-ops-04.txt Area Standards", RFC 3796, June 2004.
IETF work in progress, November 2003
[4] Philip J. Nesser II, Cesar Olvera. "Survey of IPv4 Addresses [4] Olvera, C. and P. Nesser, II, "Survey of IPv4 Addresses in
in Currently Deployed IETF Routing Area Standards", Currently Deployed IETF Routing Area Standards", RFC 3791, June
draft-ietf-v6ops-ipv4survey-routing-02.txt IETF work in progress, 2004.
October 2003
[5] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses [5] Nesser, II, P. and A. Bergstrom, Editor, "Survey of IPv4
in Currently Deployed IETF Security Area Standards", Addresses in Currently Deployed IETF Security Area Standards",
draft-ietf-v6ops-ipv4survey-sec-03.txt IETF work in progress, RFC 3792, June 2004.
November 2003
[6] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses [6] Nesser, II, P. and A. Bergstrom, Editor, "Survey of IPv4
in Currently Deployed IETF Sub-IP Area Standards", Addresses in Currently Deployed IETF Sub-IP Area Standards", RFC
draft-ietf-v6ops-ipv4survey-subip-04.txt IETF work in progress, 3793, June 2004.
November 2003
[7] Philip J. Nesser II, Andreas Bergstrom "Survey of IPv4 Addresses [7] Nesser, II, P. and A. Bergstrom, Editor, "Survey of IPv4
in Currently Deployed IETF Transport Area Standards", Addresses in Currently Deployed IETF Transport Area Standards",
draft-ietf-v6ops-ipv4survey-trans-04.txt IETF work in progress, RFC 3794, June 2004.
November 2003
8.0 Authors' Addresses 8.0. Authors' Addresses
Please contact the author with any questions, comments or suggestions Please contact the authors with any questions, comments or
at: suggestions 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
Phone: +1 425 481 4303 Phone: +1 425 481 4303
Fax: +1 425 482 9721 Fax: +1 425 482 9721
EMail: phil@nesser.com
Andreas Bergstrom (Editor) Andreas Bergstrom, Editor
Ostfold University College Ostfold University College
Email: andreas.bergstrom@hiof.no Rute 503 Buer
Address: Rute 503 Buer
N-1766 Halden N-1766 Halden
Norway Norway
9.0 Intellectual Property Statement EMail: andreas.bergstrom@hiof.no
9.0. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
10.0 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Acknowledgement
This document and translations of it may be copied and furnished to Funding for the RFC Editor function is currently provided by the
others, and derivative works that comment on or otherwise explain it Internet Society.
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.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/