<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I really, *really* hope these systems are not connected to the global
Internet! :-)<br>
<br>
I think there's likely a big difference between IPv4 end of life on the
Public Internet, and IPv4 end of life on private networks, control
systems etc.<br>
<br>
Right now the Internet is a bunch of private networks running IPv4 and
internetworking with IPv4. For the Internet to evolve it will need to
be a bunch of private networks running either IPv4 and/or v6, and
internetworking with IPv6. (If you can interconnect with v6, v4 becomes
redundant and will likely be thought of as a security hole).<br>
<br>
I don't see how two protocols, side by side on the same device are
scalable on the Public Internet for very long. We could see:<br>
<br>
1. Stick with IPv4, forget IPv6. (Ab)use NAT, trade valuable IPv4
addresses on the black market, the whole thing could keep going
indefinitely but it would get more and more in the way of commerce as
IPv4 addresses get expensive.<br>
<br>
2. Dual stack for a transition period, but who wants to double their
network administration workload?<br>
<br>
Hosting farms have very complicated setups for load balancing,
firewalls, DNS etc. I wouldn't want to keep maintaining two sets of
rules.<br>
Services providers have complicated networks, do they want to start
messing around much if they don't have to?<br>
<br>
If you look at 6PE for MPLS service providers, you side step having to
make changes in the IPv4 MPLS core, and you can easily add IPv6 at the
edge for VPNs or even the global routing table.  6to4 can do some
similar things, leveraging IPv4 networks.<br>
I don't really consider 6to4 or 6PE as dual stack, except at the edge.<br>
<br>
If I operate a large hosting site and want to start offering v6 (maybe
so developing countries can reach me natively or whatever), I'm going
to use an appliance or firewall that automates this process, leaving
existing systems alone for the time being.<br>
<br>
3. "Native" IPv6 Public Internet.  I would define this as the day one
can safely put an AAAA record in DNS as the only entry, and expect
anyone to reach it, with the onus on the querier to deal with the
NAT'ing to IPv4 if necessary.  At this point it becomes redundant to
return A records. I'm sure the IPv4 Internet will still be around but I
would assume it would mainly be carrying tunneled v6 traffic over it. <br>
<br>
<br>
<br>
Davis, Terry L wrote:
<blockquote
 cite="mid:0D090F1E0F5536449C7E6527AFFA280A0368589E@XCH-NW-8V1.nw.nos.boeing.com"
 type="cite">
  <pre wrap="">Jordi

I agree and I started to respond to a post week with a similar response and got distracted.

I can absolutely guarantee that the aviation industry expects the migration from v4 to v6 to take over 25 years.  We just expect to build airplanes that can deal with OSI, v4, and v6.  The global air traffic management system is made up of 10 of thousands of pieces controlled by approaching 1000 different organizations from small private operations to nations and v4 is already built into infrastructure pieces that are not likely to see communications upgrades for 10 to 20 years.  I routinely speak to aviation industry leaders on this and I generally place v4 end of life somewhere from 25 to 40 years out.

Likewise most critical infrastructure around the globe is the same; the SCADA that runs this today is mostly all v4 as are the hospital's (including Intensive Care Units) infrastructure around the world.  This type of infrastructure is much harder to convert than just corporate IT; it takes years of planning and scores of individual governmental design approvals/certifications to change it.

Take care
Terry

  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: JORDI PALET MARTINEZ [<a class="moz-txt-link-freetext" href="mailto:jordi.palet@consulintel.es">mailto:jordi.palet@consulintel.es</a>]
Sent: Thursday, July 12, 2007 6:44 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:ppml@arin.net">ppml@arin.net</a>
Subject: Re: [ppml] IPv4 "Up For Grabs" proposal

Hi,

I already mention this in other threads (may be not in ppml).

IPv6 has been designed to coexist with IPv4 for an undetermined period of
time. It is not expected to run *only* IPv4 since day one, and not all the
stacks actually support this. In fact, many stacks are somehow hybrids
instead of two-stacks, what it means that you can't disable IPv4 (of
course
you can let IPv4 "un-configured", which is almost equivalent).

This means that IPv4 will be here for a long time and dual-stack is the
main
transition technique. This will change with the time, at least in some
networks, once IPv6 traffic become predominant, among other economic
factors.

You always will have, at least for many years, old IPv4 boxes that can't
be
upgrades, and the easier way to reach them is if you run dual-stack, at
least in the hosts in any LAN, instead of requiring translation. This
doesn't mean public IPv4 addresses, as in most of the situations, private
IPv4 behind NAT and global IPv6 will make it.

However, the question may be different for whatever is not an end-site LAN
(for instance backbone, access, etc.), as there are already protocols such
as softwires (basically L2TP), that allow you to automatically tunnel
IPv4-in-IPv6 (or in the other way around today in most of the IPv4-only
networks), in order to be able to handle the IPv4-only applications in an
automatic fashion.

This is the case for some big networks (+5.000 sites) that we have where
the
initial deployment was completely dual-stack, and then we realized that
because the kind of traffic was becoming predominantly IPv6, and most of
the
IPv4 traffic was basically going to Internet thru proxies, it make sense
to
turn the proxies dual-stack and carry that inside the complete network as
IPv4-in-IPv6 (up to the proxy), so we had been able to disable IPv4
everywhere (except in the LANs, for both clients and servers).

This is the model that I certainly believe will be the one as IPv6
penetration becomes bigger and bigger, and then as indicated by Kevin,
IPv4
will vanish naturally ...

I've introduced the description of this scenario also in a document that
I've circulated a few weeks ago
(<a class="moz-txt-link-freetext" href="http://www.ipv6tf.org/index.php?page=news/newsroom&id=3004">http://www.ipv6tf.org/index.php?page=news/newsroom&id=3004</a>), as I believe
that this will mean less trouble for possible "new" ISPs when IPv4
addresses
are gone or "almost" gone and at the same time will help existing ISPs to
keep growing their networks without the need for asking for more IPv4
addresses to the RIR.

Regards,
Jordi




    </pre>
    <blockquote type="cite">
      <pre wrap="">De: Kevin Kargel <a class="moz-txt-link-rfc2396E" href="mailto:kkargel@polartel.com"><kkargel@polartel.com></a>
Responder a: <a class="moz-txt-link-rfc2396E" href="mailto:ppml-bounces@arin.net"><ppml-bounces@arin.net></a>
Fecha: Wed, 11 Jul 2007 14:07:16 -0500
Para: <a class="moz-txt-link-rfc2396E" href="mailto:PPML@arin.net"><PPML@arin.net></a>
Conversación: [ppml] IPv4 "Up For Grabs" proposal
Asunto: Re: [ppml] IPv4 "Up For Grabs" proposal

Why is there such a big push to drop IPv4?  Is there a reason that v4
and v6 can't operate concurrently in perpetuity?  Won't the customers go
where the content is and the content go where the money is?

I would suggest that if IPv6 is a good thing (and I firmly believe that
it is) then networks will naturally gravitate to IPv6.  That being the
case then let IPv4 die a natural death of attrition.  There is no need
to murder it outright.

If in fact IPv4 continues to survive and thrive alongside IPv6 wouldn't
that very fact demonstrate the need to keep it going and foster it?

It sounds like a lot of people have so little faith in the value of IPv6
that they for some odd reason cinsider IPv4 a threat.   If IPv6 is
better than IPv4 then people will use it.  If it isn't then they will
stay where they are.  I see no reason to 'force' people to switch.  They
will move when it is in their best interests to do so for features and
markets.





      </pre>
      <blockquote type="cite">
        <pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:ppml-bounces@arin.net">ppml-bounces@arin.net</a> [<a class="moz-txt-link-freetext" href="mailto:ppml-bounces@arin.net">mailto:ppml-bounces@arin.net</a>] On
Behalf Of Ted Mittelstaedt
Sent: Monday, July 09, 2007 4:51 PM
To: bill fumerola; 'ARIN PPML'
Subject: Re: [ppml] IPv4 "Up For Grabs" proposal



        </pre>
        <blockquote type="cite">
          <pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:ppml-bounces@arin.net">ppml-bounces@arin.net</a> [<a class="moz-txt-link-freetext" href="mailto:ppml-bounces@arin.net">mailto:ppml-bounces@arin.net</a>]On
          </pre>
        </blockquote>
        <pre wrap="">Behalf Of
        </pre>
        <blockquote type="cite">
          <pre wrap="">bill fumerola
Sent: Monday, July 09, 2007 1:32 PM
To: 'ARIN PPML'
Subject: Re: [ppml] IPv4 "Up For Grabs" proposal


On Thu, Jul 05, 2007 at 05:09:59PM -0700, Ted Mittelstaedt wrote:
          </pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">OK, then how exactly is this fact an argument AGAINST arin
                </pre>
              </blockquote>
              <pre wrap="">simply removing
              </pre>
              <blockquote type="cite">
                <pre wrap="">these records out of it's whois?  Which is what I am suggesting?
                </pre>
              </blockquote>
              <pre wrap="">who does that hurt? the legacy holders or the rest of the
              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap="">community
        </pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">trying to use a tool to find out who to contact when that
              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap="">netblock
        </pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">does something foolish.

as a paying ARIN member, i want ARIN to keep track of as much as
they're legally, financially, technically allowed to. that WHOIS
service is more useful to me, the paying ARIN member, not
              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap="">the legacy holder.
        </pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">For now.  What about post-IPv4 runout?
            </pre>
          </blockquote>
          <pre wrap="">i think you assume that ARIN's IPv4 services will change in
          </pre>
        </blockquote>
        <pre wrap="">some major
        </pre>
        <blockquote type="cite">
          <pre wrap="">way when that happens. i don't believe the memebership would
          </pre>
        </blockquote>
        <pre wrap="">want that
        </pre>
        <blockquote type="cite">
          <pre wrap="">change and the IPv6 fees at that point would cover
          </pre>
        </blockquote>
        <pre wrap="">maintanence of those
        </pre>
        <blockquote type="cite">
          <pre wrap="">'legacy' systems.  i'd imagine ripping the IPv4 components would be
more costly than just maintaining them after any sort of:
          </pre>
        </blockquote>
        <pre wrap="">ipv4 runout
        </pre>
        <blockquote type="cite">
          <pre wrap="">of addresses by ARIN, ipv6 eclipse of ipv4, ipv4 runout of
          </pre>
        </blockquote>
        <pre wrap="">addresses by
        </pre>
        <blockquote type="cite">
          <pre wrap="">IANA, etc.

i would want to see the same level of service provided. no
          </pre>
        </blockquote>
        <pre wrap="">difference
        </pre>
        <blockquote type="cite">
          <pre wrap="">between legacy pre-ARIN holders and paid members.
          </pre>
        </blockquote>
        <pre wrap="">So then if the membership doesen't want IPv4 to be removed
from the registries, then what is going to be created is a
situation where nobody has any incentive to remove their IPv4
reachability, nor remove the ability for their customers to
reach IPv4 sites.

In short, IPv4 will NEVER "go away"  Your proposing a future
were we add IPv6, and nobody ever gives up IPv4 resources.
So the Internet merely becomes an Internet of both IPv6 and
IPv4, not an Internet of IPv4 only or an Internet of
IPv6 only.

I'm not debating we could or couldn't do this technically.

However, if we do this, then don't you see that ALL IPv4
holders, not just the legacy ones, will never have any
incentive to drop IPv4.

If all of that is OK with you, then why would an existing
paying IPv4 holder today who doesen't need numbering, want to
bother going to IPv6?  After all you just said everyone will
be maintaining their IPv4, so what need is there for an
IPv4
holder to load up IPv6?  The only incentive I see would be to
reach a network that is IPv6 ONLY, such as a network that
needs numbering post-IPv4 runout.
This puts a terrible burden on these networks because since
they are new, they cannot be reached by a lot of the
Internet, and it is not likely that they can provide enough
of an incentive to get IPv4-only holders to update to reach them.

Ted


_______________________________________________
This message sent to you through the ARIN Public Policy
Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:PPML@arin.net">PPML@arin.net</a>).
Manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/ppml">http://lists.arin.net/mailman/listinfo/ppml</a>

        </pre>
      </blockquote>
      <pre wrap="">_______________________________________________
This message sent to you through the ARIN Public Policy Mailing List
(<a class="moz-txt-link-abbreviated" href="mailto:PPML@arin.net">PPML@arin.net</a>).
Manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/ppml">http://lists.arin.net/mailman/listinfo/ppml</a>
      </pre>
    </blockquote>
    <pre wrap="">


**********************************************
The IPv6 Portal: <a class="moz-txt-link-freetext" href="http://www.ipv6tf.org">http://www.ipv6tf.org</a>

Bye 6Bone. Hi, IPv6 !
<a class="moz-txt-link-freetext" href="http://www.ipv6day.org">http://www.ipv6day.org</a>

This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.



_______________________________________________
This message sent to you through the ARIN Public Policy Mailing List
(<a class="moz-txt-link-abbreviated" href="mailto:PPML@arin.net">PPML@arin.net</a>).
Manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/ppml">http://lists.arin.net/mailman/listinfo/ppml</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->_______________________________________________
This message sent to you through the ARIN Public Policy Mailing List
(<a class="moz-txt-link-abbreviated" href="mailto:PPML@arin.net">PPML@arin.net</a>).
Manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/ppml">http://lists.arin.net/mailman/listinfo/ppml</a>
  </pre>
</blockquote>
<br>
</body>
</html>