RE: Open question and Critical dependencies

[Dave Crocker <dhc2@dcrocker.net>]

> >  Forgive me, but I do not see what it is about shim6 that
> >  cannot work equally
> >  well for IPv4.
> >
>  It has to do with implementation and time to market.  shims will have to
>  map to addresses and data structures for IPv6 and that is x amount of
>  work.  Adding IPv4 increases that work to deliver.

In the scheme of design and implementation details for shim6, it would be
interesting to see the analysis that showed support for IPv4 as adding any
interesting amount of work, particularly in light of the benefit of that would
accrue from supporting the current installed base of IPv4 platforms.


>  The point of this work has always been to focus on an IPv6 solution.

Actually, that's not true.  a number of the proposals supported 4 and 6.

Yes, multi6 was chartered to work on 6.  yes, a focus on 6 dominated.

but some folks seem to be forgetting that this is a new working group and it
is getting a new charter.  if this is merely a continuation of the multi6
working group, then perhaps the current effort should be characterized as a
rechartering of multi6?


> >  It is one thing to exclude IPv4 if the work somehow,
> >  fundamentally, depends on
> >  the distinctive characteristics of IPv6.
> >
>  I suggest it does as we define mechansims to make the shim work.

It is difficult to guess how a charter can ignore an installed base of
hundreds of millions of machines, with nothing more than a guess about
possible future work.

Normally, that sort of decision ought to have some technical basis.


> >  It is another to
> >  exclude it because
> >  of an arbitrary preference.  IPv4 is the installed base.
> >
>  It is also because that is the work focus we agreed upon.

To repeat:  this is to be a new working group and is formulating a new
charter.  Nothing has yet been agreed on.


> >  My point is that NATs exist on a very large scale and they
> >  seem to exist for a
> >  variety of reasons.
> >
>  They exist for IPv4 they do not have to exist for IPv6

That is a reasonable belief, but there is no operational basis for knowing
that the market will magically get rid of NATs.

As I say, that is a very, very large gamble to take, absent solid knowledge
about end-user criteria.  The IETF has always railed against NATs; the market
has chosen to use them in spite of our expert opinion.


>  I think NAT is orthogonal to the work for shim6 technically and this
>  discussion is moot. shim6 will not benefit or detract from NAT. In any
>  form technically.

Actually, it's not.  NATs often know quite a bit of state about an association
and, therefore, are likely to take exception to a transport connection
suddently starts using a different IP Address. As I said, if this were not the
case, MAST would have been running last year.


> >  I hope you realize how much this language echoes OSI
> >  predictions made long
> >  ago.
> >
>  That is invalid comparison, OSI was a completely new protoocol and IPv6
>  is an extension to the Internet model and Ipv6 is being deployed and

The original proposal by Steve Deering was for something that could reasonably
have been treated as an IP upgrade.

The current IPv6 is far more complex and disruptive.  Adopting it is the same
as adopting an entirely new internetworking protocol.

After 10 years, we ought to deal with the reality that there is significant
resistance to adoption.


>  No one has done with the IPv6 deployment strategy at all.  IPv6 greatest
>  business and operational benefit is that it can restore the end-to-end
>  model of networking and security.

and which users have been demanding that restoration?



On Tue, 29 Mar 2005 08:46:13 +0900, Thierry Ernst wrote:
>  Are you arguing that IPv6 deployment is not underway ?

When something take 10 years to get to the point of starting infrastructure
deployment, there is usually a rather basic problem.  In particular, the world
has repeatedly seen promises of the next great technology that will see grand
deployments "soon in the future" that somehow keep being in the future, rather
than now.

Sometimes, those deployments actually do occur and I think it will be good if
this is one of them.  However the history of efforts that experience such
rolling delays is rather dismal.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net