RE: Open question and Critical dependencies

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

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

I am not into building charters but I don't support this and off this
topic. I have made my statements we can agree to not agree.

That being said of course I will look at this as implementor or I would
be stupid as IPv4 is all over the stack :--)

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

I was speaking of my interpretation of the mission and objective and my
recollection is it was IPv6.

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

Fair analysis and interpretation.  But we have enough work to do to
focus on IPv6.

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

I leave that to you all to debate charter.

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

I never speak from any position but a technical basis.  The work for
IPv6 has been sent by others.  I think it is plenty of work for this
working group.

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

Well those of us driving IPv6 deployment are working very hard to make
this happen.

> 
> 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 agree but there will be many disruptive technologies that will
influence IPv6 at the same time IPv6 is coming to the Internet.  The
need for end-to-end is great and there is real revenue on the table to
support the process.

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

My view is most NAT is in a router most shim work is in end systems.

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

I don't agree with that extreme but that is not a useful discussion for
this working group and could be a huge rat hole technically.

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

It is not resistance it is dot-bomb from to many that listened to
marketing people masquerading as engineers, Telcos being hurt by 3G
cost, and generally economic conditions.  That business climate is
changing now and also the first products were not done until 2000 and it
has taken us 4 years to truly test it etc. So 10 years is not
unreasonable to me at all. I have a slide set I do with next barriers to
deployment once I have them at URL location I can share them.  A big
barrier is applications but now all the large ERP apps are in process
and Microsoft Longhorn release in 2006 will be a key point on the Ipv6
deployment line of sight.  I could on and on with current deployment in
process and in Asia most dominant.  Not sure this conversation is useful
to the working group though?

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

DOD's world wide, Providers, 3G TEMs, and WiFi Multimedia. 

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

Ditto from above.

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

I don't agree the delays was for lack of want or need as I state above,
and we are now in opinion land for sure and two different views for
speculation.

/jim

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