RE: Open question and Critical dependencies

[Dave Crocker <dhc2@dcrocker.net>]

> >  2. Why is shim6 limited to IPv6?  What is it about the
> >  problem space and/or the solution space that is required to exclude IPv4?
> >
>  First because we have no chance of solving the IPv4 problem.

Forgive me, but I do not see what it is about shim6 that cannot work equally
well for IPv4.  That is really an underlying technical question I am trying to
ask.

It is one thing to exclude IPv4 if the work somehow, fundamentally, depends on
the distinctive characteristics of IPv6.  It is another to exclude it because
of an arbitrary preference.  IPv4 is the installed base.


> >  3. What happens to shim6 if it must operate through a NAT?
> >
>  If this is for IPv6 the deployment efforts are trying to eliminate NAT
>  as majority view out of the IETF in the deployment community.

I am not arguing about the IETF religion against NATs, or even about the
legitimate feeling that NATs are messy and the IP architectural world would be
better without them.

My point is that NATs exist on a very large scale and they seem to exist for a
variety of reasons.

To require that IPv6 be used without NATs is to assert a restriction on
current operational practice that is extremely risky, in terms of the
willingness of operations staff to concur.  Hence, it imposes a very high
barrier to adoption, given the network operations models for most IT staff and
home users.

In other words, we cannot make NATs go away simply because of IETF opinion. 
It would, therefore, be wise for an IETF effort either to be NAT-neutral, when
possible, or to deal with their likely presence explicitly and constructively.


> >  While both outcomes are appealing, all
> >  operational history to date suggests that those outcomes are,
> >  at best, far
> >  into the future, if they will occur at all.  (Predictions of
> >  changes to the
> >  installed base of widely-adopted services are almost always wrong.)
> >
>  Don't agree.  IPv6 deployment is infrastructure stage now and equipement
>  purchases to support IPv6 are in process and transition planning within

I hope you realize how much this language echoes OSI predictions made long
ago.  It was an interesting example of wishful thinking, asserted with great
vigor, all the way into extinction.

We ignore established networking practise at the very real peril of the
technology we are trying to get used.


> >  The danger of critical dependencies like these is that the
> >  current work cannot
> >  become widely useful unless and until those dependencies are
> >  satisfied.
> >
>  I think our job is to define a solution.  That is what we do in the
>  IETF. For example we defined neighbor discovery, an API, updated routing
>  protocols to support IPv6, and set of transition mechanisms they are all
>  being deployed.

When we define a "solution" that ignores established operations practise or
fails to establish strong market need, then the solution solves nothing,
because it fails to get adopted and used.




On Sun, 27 Mar 2005 21:06:12 +0200, Leif Johansson wrote:
> >  2. Why is shim6 limited to IPv6?  What is it about the problem space
> >  and/or
> >  the solution space that is required to exclude IPv4?
>
>  Because the WG is tasked with implementing a design from multi_6_ (my
>  highlights :-) and not from multi4?

In other words, the reason for excluding the entire installed base of IPv4
users is because a previous working group excluded it?

The word "tautology" comes to mind.


>  Isn't it reasonable to summarize the v4/v6 thread on this list as "if
>  we can make it work on v4 we will but it isn't a requirement" ?

Probably not, because a) it isn't in the charter, and b) my point was that
shim6 should pay serious attention to current practise.  Treating IPv4 and
NATs as if they do not (or, rather, will not) exist is not the way to do that.



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


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