RE: Open question and Critical dependencies

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

> The current draft charter prompts some basic questions:
> 
> 
> 1. What does "This solution should work whether or not the 
> peer site supports 
> the shim6 protocol" mean in the draft charter and how can it succeed?

This is important question.  My interpretation is if two nodes are
communiczting peer-to-peer nodes A and B.  Where A supports the shim but
B does not.  That A should be able to use the shim implementation if B
does not.  This is a response not that I support this shim effort yet at
this time for impelementation in products.

> 
> 
> 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. Second to
limit the scope of work. Third because the most serious issues and cause
for this work is that IPv6 could cause major per host route address
space invasion when IPv6 supports end-to-end and mobility in the market
and walled gardens go down via 3G.  In addition it will make
implementation of a solution more expedient and if it works well then a
backport discussion of IPv4 can be discussed.

> 
> 
> 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.  The one
case that will exacerbate this issue is the consumer market from the
home user who will be behind a NAT for some time where the dual IP layer
approaches will not work through a current NAT until those boxes support
protocol ID 41 (e.g. Linksys, Netgear).

But if shim6 or SCTP be were used with ULIDs for identification that
should be transparent to NAT which is an edge issue and NAT would be
dealing with IPv6 addresses not ULIDs.


> 
> 
> Items 2 & 3 establish critical dependencies on the wide-scale 
> adoption of IPv6 
> and the elimination of NATs.

I would suggest that also that NAT boxex permit v6-in-v4 and v4-in-v6
tunneling, and NAT would continue for now for IPv4, but not necessarily
for IPv6.  Thus there is a path where NAT exists for IPv4 and a
transition from NAT view with IPv6.

>  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
most ISPs and some large Enterprises, and the 3G, GSMA, etc. greenfield
providers.  So I  think we are in better shape than stated above and
several network pilots in existence today world wide are demonstrating
what I say above is in fact happening.  IPv6 for infrastructure
deployment and planning is in process and further along than many would
realize.

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

We need to define a technical solution in the IETF now for multihoming
for IPv6 the vendors and market will define how it is deployed and used.


Clearly we want to think of use and operations, but we should base our
work on trying to guess deployment or the market in this working group
or the IETF we simply are not good at that at all.

> Hence, the current charter guarantees that the shim6 work 
> will never be widely 
> useful, if IPv6 does not gain wide adoption OR if it must 
> operate through 
> NATs.

I emphatcially disagree witht the assumption to stop this work.  If one
does not beleive IPv6 will be widely deployed then I would suggest one
should not be working on this list and group and the charter to work on
Ipv6 has been here since the beginning and changing it is inappropriate
at this time.

> 
> And please note that I said "or" and not "and".  Hence, the 
> probabilities of 
> adoption barriers are multiplicative, ie, essentially 
> exponentially worse.

I don't agree.

/jim

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