RE: ocean: do not boil

[Margaret Wasserman <mrw@windriver.com>]

Hi Tony,

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

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.

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

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

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

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

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

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

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?

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

Margaret