RE: WG Review: IPv6 Operations (v6ops)

[Pekka Savola <pekkas@netcore.fi>]

Hello,

Getting back to a few points.

On Thu, 5 Sep 2002, Bound, Jim wrote:
> > On Wed, 4 Sep 2002, Bound, Jim wrote:
> > > I don't hear that from any user in that way.  What I hear 
> > is there are
> > > several good mechanisms they like and want to apply for different
> > > reasons.
> > 
> > For (over?) 95% of folks, they're just distraction.  And what 
> > we want here
> > is to get deployments going.  There's little need for 
> > anything fancy if
> > you don't require it. 
> 
> Deployment is going as best it can right now.  See the NTT MSC
> announcment that came out yesterday in Malaysia that is native IPv6.  

Native IPv6 is the proper and easy way.  The press release does not 
elaborate on the tunneling mechanisms used though.  And there's nothing to 
suggest v6-only (which was one of my "not of this world" arguments) there.

> I
> don't think ISATAP, DSTM, or Teredo are "fancy" but solid mechanisms
> that work and for those moving at very fast pace.

Some are more useful than others.  I suppose they work, more or less, in
more or less restricted topologies.  I have doubts about the stability in
the long term or when more people would start to use them.
 
> The mechanisms I feel are imperative for wide deployment are as follows:
> 
> Basic Tunnels
> 6to4

Sure.

> ISATAP

May be useful in some scenarios (IMO, especially large enterprises with 
slow and sparse deployment or a lot of internal traffic).

> Teredo

Have you read the latest versions of the draft?  It's a patch over a patch
over a patch against (mis)features of NAT (not a fault of the author of
course).  It's just too complex to work reliably.

I would rephrase this as:

"Some reliable and simple mechanism to provide v6 behind a NAT"

(Yes, it's possible -- but there are some engineering tradeoffs!)

> DSTM

I'm not yet convinced of this.  Especially I have huge doubts about 
temporary address management scalability and robustness.

> BIA (in some cases but caution is needed)

May be useful for legacy apps, yes.
 
> NAT-PT and SIIT should be last resort and not used unless there is no choice.

Agreed.
 
> What is happening is that unless vendors, operators, and some other
> entities I won't mention begin to make money on IPv6 they are going to
> stop momentum.  Fortuneately we are seeing real purchase orders for IPv6
> and boxes and software be sold at significant levels to warrant
> continued engineering and market investments. But those returns are not
> from the large mass that will move with LCD mechanisms or the 80% that
> will do as you say and want universal solutions (as Brian suggested).
> 
> So the catch-22 is that the 20% of custom users is where we will all
> make our money for the next 3 years.  Then the masses will begin
> conversion.  So my issue is that to stop work on what we are doing that
> will make money is crazy in the IETF.  Maybe we need an advanced Ipv6
> transition area as Brian suggested but if that don't happen fast the
> vendors and entities that want to deploy this 20% will not wait for the
> IETF and do it out of band and create a storm of defacto standards for
> IPv6 that will compete with the IETF in the market.  They have no choice
> and will not loose the mony waiting on 2 and 3 year discussions of how
> to do transition or settle for universal compromised solutions.

But are those 20% of users such that they *need* a "custom" transition 
mechanism?  Why not e.g. consulting them how to build their network using 
current mechanisms?

> > I don't think all of these non-basic, complex, fringe(?) 
> > mechanisms should
> > be discarded -- quite the contrary.  But this is probably(?) 
> > not the right 
> > place.
> 
> I am not sure yet.  Randy Bush has been saying IPv6 is here as operator
> and I agree. How IPv6 deploy is still TBD.  Why should not this true 20%
> deployment sector recieve the work from v6ops effort?  I think not doing
> it is not wise.

Randy Bush has a network/ISP operator background AFAIK.  Deploying IPv6 
there is a much more simple task than deploying it properly in 
organizations.

There's much more to 'IPv6 is here' than having it enabled on dual-stack
routers.

> > I could say probably over 99% of folks doing this are not living in 
> > today's world.
> 
> This is simply not true I hope my above mail helps change your mind on
> this statement above as its as far as I can take to convince you and
> others.

See comment above, I don't think v6-only is really here yet.
> 
> > 
> > IPv4 just isn't ready to be "as-needed" at the moment, or 
> > you're probably
> > using it in very simple ways (e.g. www browsing only which works quite
> > well with NAT too :-).  It's IMO very questionable to approach IPv4 
> > needs with an "ad-hoc" ways when clearly the requirements for 
> > IPv4 are 
> > not, in reality, ad-hoc.
> 
> Ad hoc means the use of IPv4 is dicouraged as a policy and used only
> when necessary.  So maybe adhoc was wrong term on my part.

And if it's necessary for a node to use it, 10, 100, 1000 times a day?  Is 
Ad-hoc really the best way to go?
 
-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords