Re: FW: I-D Action:draft-narten-ipv6-statement-00.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
 | Ietf@xxxxxxxx
 | https://www1.ietf.org/mailman/listinfo/ietf

-- 
--
//===================================================================\\
| Mohsen Souissi             		             	              |
| AFNIC - Responsable R&D                                             |
| Mohsen.Souissi@xxxxxx  | 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]