RE: ocean: do not boil

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

Margaret Wasserman wrote:
> > > 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...
> 
> Not necessarily.  We have mechanisms, such as 6to4 and other 
> tunneling mechanisms, that will allow sites with an IPv4-only 
> ISP to obtain IPv6 service from a separate provider.
> 

You have not been reading Randy's messages closely:
... 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. ...
... if they want to provide the service, they need things like mains
power, the appropriate ip service ...
...if you want folk to access your server over tv, you need to put it on
a tv service. if you want it on v4, you need to put it on v4.  same for
v6 ...

his stated premise is precluding generic IPv4-only to IPv6-only
translation, but he is continually casting that in the realm of the
unrealistic scenario where everyone simply subscribes to an IPv6
service. 


> For example, my ISP is IPv4-only, but I have IPv6 on my home 
> network through a 6to4 gateway.  I can use IPv4 to access 
> IPv4 services, and IPv6 to see the dancing kame (the only 
> IPv6-only service I've ever accessed).  All this is 
> accomplished without translation, and without the need for a 
> v4-only node to access v6-only services or vice versa.
> 

I presume you do this for the same reason I do, you can't subscribe to
an IPv6 service. In our cases we appear to be some of the lucky few with
public IPv4 addresses so we can make 6to4 work. For all those stuck
behind an ISP nat, their only hope is an IPv6 over UDP/IPv4, but that is
not "critical" to an ISPs perspective on what it takes to deploy IPv6,
but is absolutely so for the site connected to an ISP with a glacial
pace. In any case, you haven't gotten to the point where you have an
IPv6-only device that needs to talk to the IPv4-only printer that the
vendor will refuse to build an IPv6 stack for. When you do you will find
that bouncing everything through a dual-stack print server works, but
leaves the IPv6-only device with a different view of the printer than
the rest of the nodes.

> > >
> > > 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.
> 
> One of us must be misunderstanding what Randy is saying...
> 
> When did he say that you "can't use tunneling technologies"?

When he repeatedly slipped in the requirement that anyone wanting to
export an application over IPv6 needs to subscribe to an IPv6 service. 

> 
> >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?
> 
> It isn't proper engineering to build a complex solution when 
> a simple solution exists, particularly if the complex 
> solution will have long-lived architectural consequences.

The whole world is a nail when you have a simple hammer...
The point is that the simple approach *will not* solve all of the
problems. It isn't proper engineering to ignore a large part of the
problem space simply because a tool exists to solve the easiest pieces.

> 
> >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.
> 
> What are the cases where customers are stuck at this last 
> resort point?

I can't go into details, but one decide to go there to avoid building a
fresh IPv4/nat network, only to convert it to IPv6 on or before
completion. The other is a case I was working on today where a customer
was sold a bill of goods about dual-stack end systems being more complex
and unstable by another supplier. All I can do in these cases is point
out what is required to make it work, and what costs would go away if
they could figure out a dual-stack deployment. 

> 
> How are translation tools easier, cheaper or better to deploy 
> in those situations than running IPv4 and IPv6 in parallel?

Both of the cases I have been involved in are fresh networks with over
500,000 end systems. It is very hard to argue that deploying IPv4/nat at
that scale is cheaper than deploying nat-pt.

> 
> >The process of declaring those
> >situations out of scope...
> 
> There is a big difference between suggesting that something 
> may not be needed and "declaring it out of scope".  We have 
> at least one translation tool in our charter (NAT-PT), so no 
> one has declared them out-of-scope for this WG.  Or, at least 
> if they have, they haven't told me :-).
> 

>>  let's not go there

How else do you read that? Particularly when the current problem space
is being documented, but still incomplete.  How do we know what is not
needed?

> What are the technical reasons why it would ever be the best 
> choice to use a IPv4<->IPv6 translation tool?

When it is not worth the cost to upgrade a machine that will be thrown
away once it is fully amortized, but the service it provides needs to be
accessed from new IPv6-only nodes. I am sure someone will argue that an
application specific proxy could be built, but why would we require
everyone to build a unique proxy when we could finish a generic
translation tool, but refuse to because it is not critical to an ISPs
view of a deployment.

> 
> Bob Hinden raised the suggestion that we might want folks to 
> be able to build IPv6-only equipment, but still have that 
> equipment access IPv4 services.  That may be an interesting 
> longer-term cases.  At the moment, though, does anyone even 
> ship a stack that can be built in an IPv6-only configuration?

Just because it is not public doesn't mean it doesn't exist. If the wg
is going to have such a short term focus that it can only deal with the
network that will exist in the next 6 months, there will be chaos.

> 
> >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.
> 
> Right.  And, why is that worse than deploying IPv6<->IPv4 translation?
> 
> Maybe there is a good reason why it is worse...  I just don't 
> know what it is.
> 

If you have to deploy translation anyway, why take a giant step backward
that will have to be retraced in short order? The people building these
networks are trying to do prudent engineering, and their cost minimum is
coming out in a much different place. Rather than recognize that
difference and deal with it, the approach appears to be to claim the
IETF knows better, so figure out how to use our simple hammer to screw
in your light bulb.

Tony


> Margaret
> 
> 
>