RE: Open question and Critical dependencies

["Bound, Jim" <jim.bound@hp.com>]

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

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

If the architecture and specs completed support IPv4 that is useful I
agree but our technical focus here is IPv6 and IPv6 architecture and
dynamics in implementation has characteristics that don't exist in IPv4.
For example if we want to pass shims between peers we can do that quite
nicely with IPv6 as Ext Hdr or DST option for IPv4 we have to do it
another way.  That is more work.

Thus the main concern is time-to-market for IPv6 multihoming from this
work not IPv4 and always has been the rules of engagement.

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

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

Nor am I.

> legitimate feeling that NATs are messy and the IP 
> architectural world would be 
> better without them.

But this is aximatic.

> 
> 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 and they are
being avoided now in the IPv6 deployment stage.  Clearly there will be
isolated cases.
 
> 
> 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.

This is why IPv6 WG deprecated NAT-PT spec we cannot propogate NAT in
good coscience.

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

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

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
planned already far beyond anywhere OSI was ever done.  It is now a
requirement for implemementation in specific markets and vendors are
making money on IPv6 already which they did not with OSI.  

>  It was an interesting example of wishful thinking, 
> asserted with great 
> vigor, all the way into extinction.

Comparing OSI and IPv6 is like comparing apples and oranges. 

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

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.  All I know realize we need to migrate
from NAT and do it wisely.

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

I agree and no one is proposing that and on the contrary the charter
does a good job of isolating the work and the eventual solution.

I think we are in agreement but coming at it from two different views.

/jim