Re: Dominant IPv6 Network deployment for Transition by Users

[Marc Blanchet <Marc.Blanchet@hexago.com>]

-- Thursday, June 24, 2004 00:09:27 +0300 Pekka Savola <pekkas@netcore.fi>
wrote/a ecrit:

> On Wed, 23 Jun 2004, Bound, Jim wrote:
>  
>> 3. It is far easier to control the operation of transition to IPv6 once
>> IPv6 networks are dominant and IPv4 is treated as legacy.
> 
> Do we (and the customers, or at least the majority of them) actually
> want to control the operation of transition to IPv6-only at this
> point?  I imagine most would want to deploy IPv6 because it brings
> them a benefit they want.  Until a significant portion of the Internet
> has adopted IPv6,

which Internet are you talking about? The IPv4 one or the IPv6 one. This is
important. If you look around, new kind of applications are driving IPv6,
because of its feature. Those applications won't be deployed on IPv4. So,
the point here is there is two Internet: IPv4 Internet and IPv6 Internet.

Now, with this in mind, some applications providers are deploying IPv6
networks, just because their application won't be deployed on IPv4.

Now, back to your statement: "Until a significant portion of the Internet
has adopted IPv6". This is very dangerous, since it assumes that services
and applications are moved to ipv6. No one will move to Ipv6 just for a
better "web" service.

So, what we are seeing, is a new Internet based on IPv6 with new
applications. This is _very_ significant to the whole purpose of IPv6.
These applications and networks, IPv6 only, might not be as big as IPv4
now, but they are going to make the paradigm shift. 

In summary, are we throwing away the applications and networks that are
_really_ using IPv6 features, just because they do not seem to appear in
some people radar while they connect to the current Internet?

> an easy strategy could be to postpone the decision
> on when to move to IPv6-only. 

it is happening right now. And it is very important for the immediate
future of IPv6. These applications and networks are driving IPv6. Waiting
until some narrow radar screen see IPv6 in your neighborhood is very
dangerous.

> You're assuming that it's useful to
> make the decision at this point, as a "future investment" and a hope
> that IPv6 will actually be globally deployed soon enough to warrant
> doing it now.
> 
> This might not hold.  At least in many circles, where IPv6 is *NOT* a
> "religious" or political topic (but operational one, as it should be,
> in the end -- we're not deploying IPv6 for its own sake, but to make
> the users happier by giving them better means to achieve X, Y and Z!),
> it's much easier to control the operation of transition by deploying
> IPv6, but not by taking away what's already in there (IPv4).  Then
> IPv6 will fly when there is use (X, Y, or Z, above) for it.
>  
>> The technology questions to discuss to support the above are as follows:
>> 
>> 1.  What are the differentials regarding technology requirements for a
>> gradual IPv4-IPv6 versus agressive IPv6 transition for deployment to use
>> a dominant IPv6 network deployment strategy?

not the right question. For applications that are IPv6 only because they
can't run over IPv4, what is the requirement to deploy an IPv4 network?

> 
> Good question, even though I'd personally want to question the latter 
> strategy in the first place.
>  
>> 2.  What are the Internet infrastructure requirements for that which we
>> have dominion over within the IETF regarding "protocols" and
>> "operational procedures" we specify to suppport a dominant IPv6 network
>> deployment strategy?
> 
> Regarding the previous question, I'd be interested in hearing more
> opinions on whether this is a priority work item for us?
> 
> I.e., I'm sure that (provided that IPv6 will kick off in a major way)  
> some years in the future the IETF will be specifying how to deal with
> a lot of issues regarding IPv6-only or dominant IPv6, but doing so
> *NOW* seems premature (especially as we have as little real
> operational experience from that), when we could be using that energy
> to solve the problems with the more generic approach, dual-stack.

I'm confused about this argument that is restated all the time.
- from ngtrans to v6ops, we have spent years (I don't recall, it is so far
now). During that timeframe, we could have published many transition
mechanisms and then have the market/community/... pick and choose. Then,
right now, we would be fixing issues with _real_ deployment experience, and
then in a position to move forward to another level the mechanisms that
have no issues, are well deployed, etc...

We now get the argument of "priority" and wg time. I made a suggestion in
this thread: have a small design team work on the dstm spec, come back to
wg with a final proposal, and then move it. The "work load" for the wg
won,t be  significant and we have a spec out for implementations to interop
and deploy. Same argument/suggestion stands for the other mechanisms.

Instead of "fighting" on one or the other mechanism, questioning some
variation of some requirement, where we spend a lot of "wg important time
and priority", we could instead work on protocol design and publish. 

I'm pretty sure we could reach concensus on a set of mechanisms that some
of us have implemented and then publish them. This won't be that difficult.
and will be useful for IETF, for the IPv6 community and market, and will
leave this infinite loop we have started years ago with the ngtrans-2-v6ops
"transition"...

my 2 canadian cents...

Marc.



> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 



------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------