Subject: ocean: do not boil

From: Randy Bush <[email-masked]>
Date: Sat, 21 Sep 2002 06:34:12 -0700

first, thanks for doing a great job in sunnyvale.  i think it was
worth the effort and pains.  of course, time will tell, as we see
how the scenarios flesh out.

but, i have been rather worried by one vector.  

i don't think we should try to solve the problem of an arbitrary
user/service on a pure v6 site/host trying to communicate with a
user/service on a pure v4 site/host or vice versa.

dns is critical infrastructure, and we need to understand how
everyone will see the same namespace whether they are on v4 or v6
transport [0].  and we have some clues on how to do that, point
mono-stack resolvers at dual-stack caching servers.

but services such as http, smtp, blah, blah, blah just can't be
completely transparent, and we *vastly* increase the size of the
problem if we try to make them so.

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.

if i want to send mail to v4 users and i live in a pure v6 world,
then i can make an arrangement with a dual-stack relay to provide
forwarding service to me.  and to receive mail, i can just point an
MX naming an A record to a dual-stack forwarding service.

if i want to play a net.game which is in v6-land, then i need to be
at least partially in v6-land.  no magic.  tough patooties.

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.

randy

---

[0] - if you're in private v6 space, i.e. site local or other
      1918-envy games, use multiple views just as a v4 1918 site
      does today.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 21 Sep 2002 17:00:25 +0300 (EEST)

> user/service on a pure v4 site/host or vice versa.
[...]

My feelings exactly.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "Jim Fleming" <[email-masked]>
Date: Sat, 21 Sep 2002 17:24:23 -0500

IPv6 users are like people on boats yelling to people on land that they (on the boats) are on land.
The boats may get larger, but they are still floating and not land.
The boats may become islands for people from the continents to visit, but few will.
It is much easier to add a second story and more to all of the places on the continent...
...as opposed to trying to convince people they need to move to a boat and an island for more space...
...people do not see that the risk has a pay-off....
...especially when obvious expansion solutions are in in front of them...
...as the islands regress and become boats, the boats can be moved ashore and mapped to land...
...some can continue to stand at the wheel of their boat and **think** they are on the ocean...
...put them in the desert and let them look at the mirages in the heat of the day and they will be fine...
...full-steam ahead....the S.S. ICANIC is ready to launch...

---

From: [email-masked]
Date: Sun, 22 Sep 2002 11:06:24 +0900

>> user/service on a pure v4 site/host or vice versa.

	seconded.  the internet is so successful since it was designed under
	"keep it simple and stupid" approach.  i think it critical to follow
	same way for IPv6 be successful (and this is one of the reason why
	IPv6 is following a lot of IPv4 design principles).

itojun

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 22 Sep 2002 10:44:36 -0400

>user/service on a pure v4 site/host or vice versa.

I agree with this.

We need to focus on the scenarios that are most likely to occur
in the next few years, as IPv6 is added to the existing IPv4
infrastructure.

In this immediate future, most networks/hosts will continue to have
some IPv4 connectivity, often using NAT.  IPv6-only hosts are likely to
be limited to special-purpose devices that only need to reach specialized
IPv6 services.  We so need to support IPv6-only services, but it isn't
necessary for IPv4-only nodes to be able to participate.

So, there shouldn't be a need for direct IPv4-only <-> IPv6-only
communication.

Margaret

---

From: Bob Hinden <[email-masked]>
Date: Sun, 22 Sep 2002 12:19:41 -0700

>>user/service on a pure v4 site/host or vice versa.

I don't agree with one case of this.  I think there is a need to have IPv6 
only hosts that are able to reach the same IPv4 services that an IPv4 host 
behind a NAT today can reach.  This will make IPv6 only hosts much more 
attractive than if they can only reach IPv6 services.  This will make IPv6 
only a real possibility for new deployments of new types of devices.  If we 
don't support this case, then these devices (and resulting infrastructure) 
will have to be dual stack.

I do agree that doing more than this case is not necessary.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Sep 2002 09:52:07 +0200

Randy Bush wrote:
...
> user/service on a pure v4 site/host or vice versa.

Agree but:
...
> today.  as v6 deploys, folk every useful site will do so.

Alternatively, arrange to have a dual stack HTTP proxy in the right
place. Effect is the same, but like a dual stack SMTP relay it allows
a v4 only host to play HTTP with a v6 only host.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Mon, 23 Sep 2002 11:03:40 +0300 (EEST)

> a v4 only host to play HTTP with a v6 only host.

Note that Randy said 'want my web site seen by both v4 and v6 users', not 
'want my client to reach both v4 and v6 sites'.

In all cases I can think of, if you want your web content be available for 
both v4/v6 users, you should run it on dual stack at least for now: you 
shouldn't have to rely on the the clients being able to perform transport 
IP version changes (like with ALG).

From the client perspective I agree that dual-stack web proxies seem like 
a very interesting and probably quite robust approach.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 23 Sep 2002 08:05:27 +0000

> behind a NAT today can reach.  [...]

in the specific case of dns, we (isc) agree with this and will be adding
an application level capability to choose a specific forwarder set when
recursion requires contacting an "A RR" on a host with only ipv6 interfaces.

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 23 Sep 2002 14:43:11 -0700

This was the primary reason I stressed that ngtrans needed to focus on
the dual stack approach first. Even though that is a much simpler
approach, there have been a variety of situations exposed over time to
show that it simply not possible for everyone to take the easy road. The
most obvious case at the moment is the substantial deployment of
IPv4-only NAT CPE that for financial reasons *will not be upgraded*
until the ISP is ready to provide native IPv6 support (in North America
that is looking like ~2006, or in the case of docsis devices much
later). For those end sites that want to move sooner, and don't have a
reasonable option for an alternate ISP, just saying we only support dual
stack is telling them they can't use IPv6 capable apps & appliances for
at least 5 years. This will in turn put a damper on the app development
community, because to get their app deployed in that timeframe they will
have to figure out how to do nat traversal. Once they have gone down
that path, where do they find additional incentive to put in IPv6
support? 

Yes the alternative tools add complexity, but in the grand scheme of
things, is that complexity less than the mess we would end up with if
everyone came up with their own nat traversal schemes? I think it is,
and that we need more than dual stack.

Also, as a meta point, declaring an approach for transition out of scope
before the scenario documents are done is just a bit short sighted.
Indeed there are a few ISPs deploying native service today, and these
will simplify the global transition. To extrapolate from there that dual
stack is all we need is really doing a disservice to the entire effort
to make the transition as smooth as possible for the end site. Just as
there is no single network design that works for all sites, there is no
single transition approach that will work universally. Before deciding
what problem doesn't need to be solved, why don't we get working group
consensus on the problems that the design teams are trying to describe
to see what they believe (due to first-hand experience or customer
feedback) are the real problems existing networks will face as they try
to move.

Tony

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Bush
> Sent: Saturday, September 21, 2002 6:34 AM
> To: Bob Fink; Jun-ichiro itojun Hagino; Margaret Wasserman
> Cc: [email-masked]
> Subject: ocean: do not boil
> 
> 
> first, thanks for doing a great job in sunnyvale.  i think it 
> was worth the effort and pains.  of course, time will tell, 
> as we see how the scenarios flesh out.
> 
> i don't think we should try to solve the problem of an 
> arbitrary user/service on a pure v6 site/host trying to 
> communicate with a user/service on a pure v4 site/host or vice versa.
> 
> everyone will see the same namespace whether they are on v4 
> or v6 transport [0].  and we have some clues on how to do 
> that, point mono-stack resolvers at dual-stack caching servers.
> 
> but services such as http, smtp, blah, blah, blah just can't 
> be completely transparent, and we *vastly* increase the size 
> of the problem if we try to make them so.
> 
> 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.
> 
> if i want to send mail to v4 users and i live in a pure v6 
> world, then i can make an arrangement with a dual-stack relay 
> to provide forwarding service to me.  and to receive mail, i 
> can just point an MX naming an A record to a dual-stack 
> forwarding service.
> 
> if i want to play a net.game which is in v6-land, then i need 
> to be at least partially in v6-land.  no magic.  tough patooties.
> 
> 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.
> 
> randy
> 
> ---
>

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 23 Sep 2002 18:12:30 -0400

Hi Tony,

>The most obvious case at the moment is the substantial deployment of
>at least 5 years.

I'm not sure how this follows from Randy's comments...

If a node in the end site wants to access an IPv6-only service, the user
would need to install IPv6 on that node (or buy a new appliance with
IPv6 included, etc.).  If the IPv6 infrastructure isn't present to route
IPv6 natively, then they might use one of our several tunneling mechanisms
to tunnel the packet over the IPv4 infrastructure to an IPv6 network.

>before the scenario documents are done is just a bit short sighted.

I actually think that we were discussing some prioritization of the
scenarios, not declaring any of the solutions in or out of scope.

Once we have a full set of scenarios, I think it will make sense to
try to trim down the set of scenarios, based on what we think is most
likely to occur.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 23 Sep 2002 18:16:53 -0700

Margaret Wasserman wrote:
> >reasonable option for an alternate ISP, just saying we only support 
> >dual stack is telling them they can't use IPv6 capable apps & 
> >appliances for at least 5 years.
> 

>> 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. 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. The hidden and
invalid assumption in Randy's comment is that the IPv6 network is
contiguous. 

> 
> If a node in the end site wants to access an IPv6-only 
> service, the user would need to install IPv6 on that node (or 
> buy a new appliance with IPv6 included, etc.).  If the IPv6 
> infrastructure isn't present to route IPv6 natively, then 
> they might use one of our several tunneling mechanisms to 
> tunnel the packet over the IPv4 infrastructure to an IPv6 network.

This is specifically what Randy's note was asserting, that we don't need
the complexity that the mechanisms bring to the table. 

> 
> >Also, as a meta point, declaring an approach for transition out of 
> >scope before the scenario documents are done is just a bit short 
> >sighted.
> 
> I actually think that we were discussing some prioritization 
> of the scenarios, not declaring any of the solutions in or 
> out of scope.

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

> 
> Once we have a full set of scenarios, I think it will make 
> sense to try to trim down the set of scenarios, based on what 
> we think is most likely to occur.
> 

This is absolutely silly. The whole exercise is designed to refocus on
the scenarios that are actively being deployed, or currently on the
drawing board for deployment. Claiming that we can out guess the market
acceptance of those and whittle that down further presumes access to a
crystal ball I haven't seen yet. Prioritizing based on relative broad
applicability would make sense if there were limited resources, but we
seem to have plenty of interested participants. Developing them in
parallel doesn't appear to be a problem, so why artificially restrict
the working set? 

Tony

---

From: [email-masked]
Date: Tue, 24 Sep 2002 11:55:23 +0900

>invalid assumption in Randy's comment is that the IPv6 network is

	so we need to get small (< $200) router vendors to do IPv6.  upstream
	can be IPv6 over PPPoE (if upstream ISP supports it), or 6to4.
	if these small router vendors are using IP code from Linux, BSD or VxWorks,
	it's no-brainer, code is already there - more problem reside in education
	(for support call desks).  if we've done that, we can simplify it very much -
	no need for NAT penetration like Teredo.

itojun

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 23 Sep 2002 22:23:02 -0700

> 	no need for NAT penetration like Teredo.

Just because a new device exists, doesn't mean that the service
providers will deploy it. Unlike the past few years, there will need to
be a strong motivation to replace CPE gear that is not completely
amortized yet. If you want to have an impact, put effort into getting a
docsis spec for IPv6 in place. Without that, it won't matter if the
consumer puts in a $100 router because it will still have an IPv4-only
device in its path.

Tony

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 Sep 2002 09:09:08 +0300 (EEST)

On Mon, 23 Sep 2002, Tony Hain wrote:
[...]
[...]

In the case of xDSL, using bridged ATM encapsulation is enough, you don't 
need to worry about IPv4-only properties of CPE.

[...]
> For those end sites that want to move sooner, and don't have a

I don't think anyone has suggested that we don't try to find some 
solutions which enable these users, too, to get IPv6 connectivity.

[...]
> feedback) are the real problems existing networks will face as they try

It seems some design teams move faster than others: unmanaged networks 
team IMO was already working on solutions.  At this point, until we know 
the problem space better, I think it's best to assume "don't try to solve 
every possible problem unless shown otherwise" -stance.

---

From: [email-masked]
Date: Tue, 24 Sep 2002 16:00:41 +0900

>consumer puts in a $100 router because it will still have an IPv4-only

	who in this group participates to docsis group?  what is the
	relationship between IETF and docsis group? (are there any kind of
	relationship like IETF-3GPP?)  if there's anything i/we can do, i
	think we should do that.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Sep 2002 11:46:28 +0200

>         no need for NAT penetration like Teredo.

Indeed. This was the thinking behind 6to4 all along. But we do need the
$200 devices to enable it by default.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Sep 2002 11:49:03 +0200

> consumer puts in a $100 router because it will still have an IPv4-only

Why we standardised tunnels and 6to4. But they do have to allow type 41.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 24 Sep 2002 04:38:15 -0700

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

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

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

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

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.

randy

---

From: Rob Austein <[email-masked]>
Date: Tue, 24 Sep 2002 12:07:51 -0400

> 	relationship like IETF-3GPP?)  if there's anything i/we can do, i

There's no current formal liaison relationship between the IETF and
Cablelabs (the DOCSIS people), but the subject has come up recently
for other reasons, and a few IAB and IESG folks have an action item to
talk to Cablelabs about a liaison (see recent IESG minutes).

I forwarded Itojun's message to the folks who are looking into this.
Don't hold your breath waiting for a reply, this is still at a very
preliminary stage and it's too soon to tell where it's going to go.

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 24 Sep 2002 12:41:48 -0700

Randy Bush wrote:
> > 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.

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

---

From: Randy Bush <[email-masked]>
Date: Tue, 24 Sep 2002 13:22:24 -0700

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

nice hyperventilation.  but if you'll look at the beginning of this
thread, the basic idea is that we should not try to provide v4<->v6
access to *all* services.  in fact, i listed the service(s) which
_must_ be interoperable.

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

no, but nice emotional appeal.  those evil isps just won't let good
red-blooded amurikans do anything.  we should put them in jail.

it merely says that when you decide to provide a service you must
have the tools to provide it.  if you want to provide email
service, you need smtp, not http.  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.

> work on the problems.

there is an abundance of people willing to make careers at making a
complex world to try to put marketing whitewash on the fact that it
is still hard to have a merged v4/v6 infrastructure because
  o few vendors make the hardware
  o there is no motivation to move to v6

it's like the failing sales force going back to engineering for an
endless list of features which they hope will sell the product.
a good recipe for turning a failing sales force into a failing
company.  

but this is the engineering department, and our task is to do our
job prudently and properly.  we need to make sure that the *basic*
and *critical* things needed to operate v6 in a v4 world can be
done, and done reliably and scalably.

randy

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 24 Sep 2002 16:39:22 -0400

Hi Tony,

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

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

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

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

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 24 Sep 2002 16:20:01 -0700

Randy Bush wrote:
> nice hyperventilation.  but if you'll look at the beginning 
> of this thread, the basic idea is that we should not try to 
> provide v4<->v6 access to *all* services.  in fact, i listed 
> the service(s) which _must_ be interoperable.
> 

So we should provide application proxies for the services that we know
work through IPv4 NAT. More to the point though, the *only* services we
should be worried about are the ones that are important to ISPs. If it
is useful to an end site, but not to an ISP it doesn't matter. 

> Specifically 
> > 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.
> 
> no, but nice emotional appeal.  those evil isps just won't 
> let good red-blooded amurikans do anything.  we should put 
> them in jail.
> 
> it merely says that when you decide to provide a service you 
> must have the tools to provide it.  if you want to provide 
> email service, you need smtp, not http.  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.

So now I am confused. Is the tool set we defined for providing IPv6
service, even when intermediate ISPs do not, in scope or out? How does
the end node know when the IPv6 service it sees is based on a real
underlying ISP service, or is simply a translated service? Outside of
NAT application issues, why should it know if the service is live or
translated?

> there is an abundance of people willing to make careers at 
> making a complex world to try to put marketing whitewash on 
> the fact that it is still hard to have a merged v4/v6 
> infrastructure because
> it's like the failing sales force going back to engineering 
> for an endless list of features which they hope will sell the 
> product. a good recipe for turning a failing sales force into 
> a failing company.  
> 
> but this is the engineering department, and our task is to do 
> our job prudently and properly.  we need to make sure that 
> the *basic* and *critical* things needed to operate v6 in a 
> v4 world can be done, and done reliably and scalably.

Fine, but this didn't answer where the constrained resource is, and
there appear to be different viewpoints on what the scope of the IPv4
world is. If the scope of the working group is restricted to only those
things that are critical for an ISP to deploy service, we will be seeing
a much longer transition period, and possibly an outright failure to get
IPv6 deployed. If on the other hand the IPv4 world includes the edge
sites, we have a much larger set of tools that are basic and critical.
In particular for those sites who have had requests for public IPv4
address space turned down so they decide to go straight to IPv6 to avoid
a messy 1918/nat deployment & transition, are they restricted to web and
mail proxies? 

Tony

---

From: Rob Austein <[email-masked]>
Date: Tue, 24 Sep 2002 20:05:46 -0400

Tony, I'm puzzled by your apparent belief that the IETF should be
developing solutions to circumvent bad ISPs.  Depending on the market
environment in which such an ISP operates, this is either a regulatory
problem for the ISP's captive market or a case of evolution in action.

If there's a problem here that'd be in scope for an IETF working
group, please tell me what it is, because it's not obvious to me.

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 24 Sep 2002 17:20:58 -0700

Margaret Wasserman wrote:
> 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.

> >because those aren't 'provided', and when the provider gets 
> around to 
> >it there will be an IPv6 network service that is contiguous.
> 

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

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.

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

> 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

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Sep 2002 20:53:33 -0400

> unrealistic scenario where everyone simply subscribes to an IPv6

there's no such thing as generic IPv4-only to IPv6-only translation,
there are only mechanisms that work for subsets of apps. for instance,
most p2p apps will not work properly through such mechanisms.  those
that do work only because they have bought into a huge amount of 
complexity.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 24 Sep 2002 18:30:55 -0700

Rob Austein wrote:
> Tony, I'm puzzled by your apparent belief that the IETF 
> should be developing solutions to circumvent bad ISPs.  
> Depending on the market environment in which such an ISP 
> operates, this is either a regulatory problem for the ISP's 
> captive market or a case of evolution in action.
> 

I never claimed they were bad ISPs. On the contrary, they are the ones
that are most likely to succeed because the business side of the house
is not going to allow the engineers to arbitrarily swap out equipment
just to get the latest protocol. You might argue that we the IETF know
this protocol is for the greater good, but until it is required by
regulation, or lack of it starts seriously impacting revenue, the
existing box will stay. This is not bad, just a reality to be addressed.

> If there's a problem here that'd be in scope for an IETF 
> working group, please tell me what it is, because it's not 
> obvious to me.
> 

The IETF defined a protocol to move us beyond the addressing constraints
of what we have today. We started down the path to create tools to allow
organizations to move to this protocol at their own pace, with minimal
interdependencies, and the express goal that this would avoid a flag
day. We focused on the approach that would have the biggest payoff
first, recognizing there would need to be additional tools to fill the
holes. Unfortunately now that we have the simple tool, we are being told
that is all we need and the minimal interdependencies goal is absolutely
unimportant. Our only goal now is to make sure we have completely
polished the tools for a core-out approach. Never mind there is no
substantial business driver for that approach to work. 

We are not here to do marketing, but we have to at least understand the
money flow enough to understand which technical approaches are doomed to
fail for non-technical reasons. Since the end site is the origin of the
money, it should follow that approaches that satisfy that need first and
incrementally grow will be viable. If we insist that massive multi-party
infrastructure upgrades have to happen first, where is the income that
justifies the expense? (if someone knows please tell me because a boat
load of customers have asked) Since it will likely lag the buildout
expense by several years, will the ISP chain still be viable businesses
by then?

So to get directly to your question, what is in scope of the v6ops wg?
If it is only the set of tools that an ISP needs to build out today, how
does that fit the reality? If we require sites to subscribe to a
non-existant IPv6 service and refuse to provide standard tunnel or nat
tools, where is the incentive for an app provider to bother with IPv6? 

Basically my point is that we need to finish the scenario descriptions
and agree as a wg that these represent the problems that need to be
solved. Declaring a class of problems out of scope before that happens
is procedurally possible, but will lead to an incomplete set of tools
and possibly failure of the protocol to gain market acceptance.

Tony