Re: Open question and Critical dependencies

[Thierry Ernst <ernst@sfc.wide.ad.jp>]

Dave Crocker <dhc2@dcrocker.net> 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?
> > >
> >  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.

I second that Shim6 is a (proposed) WG for IPv6, and in such a case it
**doesn't** have to deal with IPv4 backporting (on the other hand it
**may** have to deal with transition mechanisms, i.e. compatible with
the installed IPv4 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.

I think it's the responsability of the IETF to state loudly that NAT is
a bad thing. Of course, the decision to use NAT or not doesn't belong to
the IETF - an engineering body - but to the people defining the usage of
the Internet. As good engineers, we have the responsability to inform
the people defining the usages that they should not use NAT. Like
engineers at NASA have the responsability to tell their managers that
the shuttle should not take off. 

So, we don't have to make things work for NATs in IPv6. If they use NAT
anyway, people defining usages will bear the cost and the
responsability.

(if we make things work for NATs, it's like saying, well, NAT is a bad
thing, but well, here is the solution. I don't buy this). 

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

Are you arguing that IPv6 deployment is not underway ?  


Thierry.