Thomas,
I've read the draft. I find it very well balanced. It is concise and
goes/gets straight to the point. I think it should be adopted as an
IAB statement (after stabilisation), and to the minimum an IETF
statement.
With all its imperfections, progressive migration to IPv6
towards/until full deployment appears to be the best (if not the only)
feasable and realistic solution in the the short/medium term.
People who think it is a bad idea to do so, have the right and the
duty to bring up a constructive alternative in the same time frame.
FWIW, my humble comments on the draft in the enclosed document.
Mohsen.
On 12 Nov, Thomas Narten wrote:
| Hi.
|
| A little more background/context that got me here.
|
| My original thinking was to do something like what ICANN and the RIRs
| have done, to bring awareness to the IPv4 situation and call for IPv6
| deployment. I think the IETF can say a bit more about why, and the
| threats to the internet architecture. (This came out of some
| conversations I had at the recent ICANN meeting).
|
| Maybe this could be an IAB statement. Maybe an IETF statement. I'm not
| sure. But I think it would be useful to have an "IETF voice" also be
| heard in the call for deployment. Especially since there are still
| some going around saying "IPv6 is not needed." "IPv6 is still not
| done, so don't deploy yet", etc. Does the IETF think that deploying
| IPv6 is necessary and in the best interest of the Internet? If so,
| reiterating that would be good.
|
| I think though that it needs to be relatively short (which I probably
| have already blown), and high-level, since it's really aimed at higher
| level than your typical engineer. But the overal message needs to be
| "think really hard about IPv4 exhaustion and what it means to your
| business", "get serious about IPv6", and "it's done, so don't wait".
|
| To find a good balance between "short" and also include a bit more
| detail (especially on the implications of not seeing IPv6 deployed),
| perhaps a short executive summary (which I didn't get into -00)
| followed by a bit more detail (e.g., up to 3 pages or so) would do the
| trick.
|
| Thomas
|
| _______________________________________________
| Ietf mailing list
| [email protected]
| https://www1.ietf.org/mailman/listinfo/ietf
--
--
//===================================================================\\
| Mohsen Souissi |
| AFNIC - Responsable R&D |
| [EMAIL PROTECTED] | Tél./Fax : 01 39 30 83 40 / 01 39 30 83 01 |
\\===================================================================//
[...]
1. Introduction
Over the last year, the Internet community has come to realize that
the IANA and RIR free pool of IPv4 addresses will be exhausted within
3-4 years, and possibly sooner. For example, Geoff Huston's "IPv4
Address Report" [1] strongly suggests that IANA free pool will be
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
exhausted by summer 2010, with the remaining RIR pool exhausted by
^^^^^^^^^^^^^^^^^^^^^^^^
==> As this report is live, I presume you should pick a date (for
example "as of DD/MM/YYYY").
summer 2011. However, even these projections are conservative, and
the actual dates may well occur sooner. The model assumes that the
rate of address space consumption will follow "recent history" and
not change as the free pool dwindles, and that there will be no
"rush" by ISPs and end sites to obtain additional address space
before the free pool is exhausted. Other reports also suggest that
the free pool will be exhausted soon [2].
^^^^
==> What is soon? :-)
[...]
IPv6 was developed to address the IPv4 address exhaustion problem
[RFC1752][RFC1726]. And although IPv6 has been widely implemented in
commercial and other products, widespread deployment has barely
begun. This document reiterates the IETF's support and commitment to
IPv6. IPv6 deployment is necessary to ensure the continued growth
and expansion of the Internet. Deployment of IPv6 is needed to
preserve the important properties of the Internet that have made it a
^^^^^^^^^^^^^^^^^^^^^^^^
==> This means that they are well-known by everybody... Could you give
some examples: "end-to-end communication", what else?
success and enable new generations of applications and services.
[...]
2. Exhaustion of the IPv4 Free Pool
[...]
The exact point at which the IPv4 free pool will become exhausted is
more a matter of academic than practical interest. Exhaustion of the
free pool doesn't mean that the IPv4 internet will suddenly stop
working; indeed, it will continue working as it already does --
devices that already have assigned addresses will continue to work as
they did before. However, sites needing additional addresses to
^^^^^^^^^^^^^^^^^^^^^^^^
support growth will find the cost and overhead of managing and
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
finding available IPv4 address space to increase. Holders of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
==> Apart from that, think also about sites built from scratch (for
example new companies, large companies in developing countries getting
access to the Internet, ...). I think the needs of such sites may
exacerbate the limitations of IPv4 addressing.
[...]
While some steps could be taken to alleviate some aspects of the
looming IPv4 address shortage (e.g., attempt to return underutilized
address space to the free pool, attempt to make use of "reserved"
space [draft-fuller-240space-00.txt], etc.), such steps are tactical
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
==> ref rather in the refs section...
[...]
3. The Need for IPv6
IPv6 was developed to address the inherent address size limitations
of IPv4 [RFC1752][RFC1726]. Because addressing this limitation
required changing the basic IP packet format (i.e., making
incompatible changes to IPv4), additional features and benefits were
added as well. While some of those changes have benefits for
specific environments, it is IPv6's expanded addressing capability
that provides its key value. Indeed, a number of the "improvements"
that were originally developed for IPv6 have since been retrofitted
back into IPv4 (e.g., IPsec (security) and Differentiated Services
(QOS)). Other improvements (e.g., stateless address
^^^
==> rather "QoS/CoS"?
[...]
4. The State of IPv6
[...]
Like with IPv4 (which was "completed" in the early 1980s), the IETF
continues (and will continue to) to work on individual technologies,
^^^^^^^^^^^
==> "continue"
[...]
Originally, it was expected that IPv6 would be rolled out before IPv4
address exhaustion occurred. But that does not appear to be
happening, given the current state of IPv6 deployment and the size of
IPv4 free pool. The key issue is the lack of a short-term return on
investment (ROI) for early deployers. The benefits of IPv6 are all
long-term, with the cost/benefit assessment difficult to make in
concrete dollar terms.
^^^^^^
==> Why not EURO/Yen/Crown/Dinar? ;-) // Maybe some more neutral
word may be more appropriate...
_______________________________________________
Ietf mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf