RE: ocean: do not boil

["Tony Hain" <alh-ietf@tndh.net>]

Randy Bush wrote:
> 
> >> if i want my web site seen by both v4 and v6 users, then i can 
> >> connect it to v4 and v6 space and run dual stack.  in 
> fact, i do so 
> >> today.  as v6 deploys, folk every useful site will do so.
> > Asserts that if a content site wants to be seen as IPv6 
> that it is in 
> > control and can just advertise that and all IPv6-only nodes will be 
> > able to reach it.
> 
> yup.  and if they want to be seen on broadband tv, they have 
> to get broadband tv broadcast service.

So all content sites are held hostage until their ISP gets around to
providing IPv6 service...

> 
> > The reality is that a consumer behind an IPv4-only NAT CPE 
> will need 
> > some form of IPv6-over-foo to get past the CPE.
> 
> a content site is not a 'consumer'.  they are provdng a 
> servce.  if they want to provide the service, they need 
> things like mains power, the appropriate ip service(s), etc.

This model precludes any consumer from providing content. Specifically
it precludes any peer-to-peer applications. I realize that many ISPs
currently don't like the idea of a consumer hosting personal web or mail
services, but their business practice should not have any impact on the
range of technology standards we are developing. 

> 
> > The hidden and invalid assumption in Randy's comment is 
> that the IPv6 
> > network is contiguous.
> 
> no, the assumption is that, if you are providing a service 
> you have the service to provide.

In other words, the edge sites can't use any tunneling technologies
because those aren't 'provided', and when the provider gets around to it
there will be an IPv6 network service that is contiguous.

> 
> >> trying to make pure v4 sites/hosts communicate for 
> arbitrary services 
> >> with pure v6 sites/hosts and vice verse is a nice way to make the 
> >> problem vastly more complicated, the solutions vastly more 
> complex, 
> >> and the net much less reliable.  let's not go there.
> > Sounds like precluding a class of transition scenarios to me.
> 
> exactly.  hence the subject line.  let's not pay the 90% to 
> solve the last 10% if we really don't need to go there.  we 
> are providing engineering not marketing and engineering magic.

I am not the one trying to prejudge the market needs. Since we know that
some of the transition technologies will be complex, why are we
concerned about their existence? The simplest mechanism to solve the
deployment problems will become predominate through natural selection.
If there are a substantial number of networks that can't use the
predominate tool, and we have precluded them from deploying because we
didn't finish the tool that would work, have we done proper engineering?


I can understand the desire to sort and prioritize to manage resource
constraints, but at the moment I see an abundance of people willing to
work on the problems. Where is the resource constraint we are trying to
manage? Is it the time of the DNSext wg in trying to document that the
mx record an IPv6-only node sees for an IPv4-only node needs to point to
a dual-stack MTA? Even when that is identified, is it reasonable to
prejudge a class of transition tools as out of scope when the wg is in
the midst of trying to document the cases they or their customers are
currently facing? 

Personally I will not be spending a lot of my time on translation tools,
as I tell my customers that the translation approach should be looked at
as a last resort. That said, there have been cases where those customers
are stuck at that last resort point, so I a glad there are people in the
wg who want to work out the details. The process of declaring those
situations out of scope at this point is telling sites that want to
deploy IPv6 that they need to deploy an IPv4 network, even when they
only want occasional access to the existing public Internet. Yes
application specific proxies at the edge will solve some of the
problems, but the IETF doesn't specify every possible application.
Taking the position that http & smtp are enough is focused on the
limited applications that service providers typically offer. End sites
have a much broader mix for their specific needs, so precluding generic
translation is condemning them to build their own application specific
proxy, or wait for their ISP. This puts us back in the chicken-and-egg
situation where the ISP won't deploy without demonstrated demand, but
the sites can't demonstrate demand through new apps until their ISP
deploys.  

Tony