Subject: Dominant IPv6 Network deployment for Transition by Users

From: "Bound, Jim" <[email-masked]>
Date: Wed, 23 Jun 2004 10:48:34 -0400

Many of us here working in industry with users are seeing that enough
users and entities within the Enterprise and ISP scenarios see a very
good cost justification to move to native IPv6 dominant LAN/WAN networks
for deployment for multiple reasons.

1. Moving to dominant IPv6 networks reduces cost over long transition of
supporting both IPv4 and IPv6.

2. Many believe the only real way to deliver true Mobile IP "Roaming"
across an Internet network is with IPv6 and Mobile IPv6.  

3. It is far easier to control the operation of transition to IPv6 once
IPv6 networks are dominant and IPv4 is treated as legacy.

It will take several years to achieve a strategy but the network pilots
and planning is underway today as I type this mail.

The hybrid-stack (dual stack is a misnomer in the context of this mail)
deployment model will work well with this type of deployment for legacy
requirements.

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?

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?

3.  What are the technical limitations from IETF protocol suite
perspective?

4.  What are the security limitations from IETF protocol suite
perspective?

What else needs to be on the above list?

Things we should not discuss here and not in our control within the
IETF:

1.  Vendor product delivery roadmaps of IPv6 infrastructure we specify
in the IETF and in other bodies, consortias, and forums.

2.  Application vendor product delivery roadmaps.

3.  Infrastructure software to support IPv6 like Network Management and
PKI products.

4.  User policies for deployment which will vary as much as the opinions
on this list.

5.  How IPv6 will be provided as a business by service providers either
public or private.

regards,
/jim

---

From: Pekka Savola <[email-masked]>
Date: Thu, 24 Jun 2004 00:09:27 +0300 (EEST)

> supporting both IPv4 and IPv6.

I think you assume that having to support one dominant protocol (IPv6)  
and one less dominant (but still a MUST work protocol, IPv4), through
mechanisms more complex than just deploying IPv4 (or keeping it
deployed) requires a smaller amount of support in total?

This seems dubious to me.
 
> across an Internet network is with IPv6 and Mobile IPv6.  

Sure, why not.  This is no argument for dominant IPv6 networks though.  
It's an argument for deploying IPv6.
 
> 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, an easy strategy could be to postpone the decision
on when to move to IPv6-only.  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.
 
> a dominant IPv6 network deployment strategy?

Good question, even though I'd personally want to question the latter 
strategy in the first place.
 
> "operational procedures" we specify to suppport a dominant IPv6 network

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.

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 24 Jun 2004 12:38:08 +0200

> This seems dubious to me.

There are many cases where IPv4 is quite troublesome. For instance, if 
you organize an event where lots of ad-hoc users show up, you need a 
lot of IPv4 address space that's hard to get if you don't already have 
it. And any time you build a network that has significant growth, you 
end up with very fragmented address usage, which in turn can make it 
necessary to have huge broadcast/flooding domains with all the trouble 
that entails. With IPv6, none of this is an issue, so it's much easier 
to design a network and then deploy it without having to change much 
later. Now obviously supporting v4 connectivity over tunnels brings 
back some of the v4 complexity, but I expect there will still be 
significant advantages in many deployments.

Note though that I wouldn't expect each and every host to have an IPv4 
address in such a scenario: hosts that only use simple client/server 
protocols can either use address translation or proxies.

> point?

That's not the point Jim was making. If you want to run both IPv4 and 
IPv6 there are several ways to do this: run v4 first and add v6 where 
needed (this is how it's done most of the time today), run them as 
equals side by side, or build an infrastructure that's optimized for 
IPv6 and then bring back IPv4 where needed the same way legacy 
protocols are generally supported. Whether IPv4 is actually legacy or 
not is pretty much an eye of the beholder thing, what counts is the way 
you design a network. Building a significant NAT-less IPv4 network is 
very challenging, much more so than building an equivalent IPv6 
network. Then adding back IPv4 through tunneling has the advantage that 
the address usage is no longer tied to the network topology so it's 
much easier to meet RIR policy requirements.

> I imagine most would want to deploy IPv6 because it brings
> them a benefit they want.

Simple network design and operation is what many people want.  :-)

> Until a significant portion of the Internet
> on when to move to IPv6-only.

Sure. But note that enterprise users usually talk much more amongst 
themselves than with the internet at large. The issues are different 
from ISP networks or home networks, where connectivity to the rest of 
the world is the most important thing.

Also note that this isn't a question of running IPv6-only hosts, the 
hosts will still be dual stack. It's a question of how to provide dual 
stack connectivity to a large number of hosts in the way that's most 
efficient.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 24 Jun 2004 13:18:54 -0400

-- Thursday, June 24, 2004 00:09:27 +0300 Pekka Savola <[email-masked]>
wrote/a ecrit:

> 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

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

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?

> 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.

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