Subject: IPv6-only devices?

From: Ronald van der Pol <[email-masked]>
Date: Thu, 6 Feb 2003 21:13:19 +0100

Some vendors are thinking about developing IPv6-only appliances.

I would like to know why they don't put dual stacks on their
appliances. So, if you are a vendor and are thinking about IPv6-only
appliances, please let us know why you prefer IPv6-only over dual
stack.

It may be a cost issue. But IPv6-only makes the architecture more
complex than in the case of dual stack. So, it may be a tradeoff
between dual stack appliances with a simple home router and IPv6-only
appliances with a complex home router (with NAT-PT or similar and
all its problems).

But do IPv6-only appliances really need NAT-PT? I don't think so.
If the PCs in the home network are dual stack, they can communicate
to the IPv6-only appliances via IPv6 transport.  The same is true
for PCs outside of the home network (if the home network is reachable
via IPv6 transport). The question is: is it absolutely necessary
that IPv6-only devices can communicate to legacy IPv4-only PCs?

Thinking about it I think NAT-PT will slow down the move to IPv6.
Without it, users are motivated to upgrade their PCs to dual stack
to be able to communicate with their new IPv6-only appliances.
And they are motivated to request IPv6 connectivity from their
ISPs.

Comments?

	rvdp

---

From: Keith Moore <[email-masked]>
Date: Thu, 6 Feb 2003 15:39:30 -0500

On Thu, 6 Feb 2003 21:13:19 +0100
Ronald van der Pol <[email-masked]> wrote:

> complex than in the case of dual stack.

I don't see how.  Actually the simplest way to go seems to be to declare
some apps IPv6-only, some (legacy) apps IPv4-only, and a few apps
dual-stack.  It's a lot simpler than trying to teach applications to
cope with a mixture of the two - which gets you back to the problems
inherent in scoped addresses.

Keith

---

From: Ronald van der Pol <[email-masked]>
Date: Thu, 6 Feb 2003 21:56:43 +0100

On Thu, Feb 06, 2003 at 15:39:30 -0500, Keith Moore wrote:

> It's a lot simpler than trying to teach applications to

I don't agree. Applications that walk all addresses (v6 and v4) are
widely deployed without any problems. I am thinking about ssh, http,
smtp, etc. Porting applications to use both v4 and v6 addresses is
in many cases easy.

It seems like what you are promoting is balkanizing the internet.
Some nodes are v4-only and can only talk to v4-only. Other nodes
are v6-only and can only talk to v6-only. Is that what you want?

	rvdp

---

From: Pekka Savola <[email-masked]>
Date: Thu, 6 Feb 2003 23:02:57 +0200 (EET)

On Thu, 6 Feb 2003, Ronald van der Pol wrote:
> widely deployed without any problems. [...]

I'm not sure if this is trivial.  I have yet to see the influx of
"production" services which have both A and AAAA records for a DNS name.

It could be harder than we imagine..

> I am thinking about ssh, http,

I agree, porting is the easy part..
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Keith Moore <[email-masked]>
Date: Thu, 6 Feb 2003 16:16:09 -0500

On Thu, 6 Feb 2003 21:56:43 +0100

> smtp, etc. Porting applications to use both v4 and v6 addresses is

This works great for some applications; really poorly for others.
In general it works for apps that only involve two parties, and thus
two network endpoints.  There the rules are simple.  If both speak
v6, use v6.  Else, if both speak v4, use v4.  Otherwise, you may be
out of luck.  (actually this is likely to cause painful delays for
dual-stack hosts, but for the moment let's ignore that problem)

Surprisingly few apps work this way.  For instance the web doesn't work
this way.  The vast majority of the content on the web is accessible
only via IPv4.  If your client can't get to IPv4, you lose.  Email
doesn't work this way either.  Everyone needs an MX that speaks IPv4.
Yes, you can use a web proxy to allow your v6 client to get to the v4
web, and you can use a mail relay to allow your v6 client to relay mail
to the v4 mail network.  Both protocols already support a form of
proxying, so no protocol changes are necessary.  But you still end up
requiring an operator to make protocol-specific arrangements in order
to permit allow cross v4-v6 operation. And if you want your v6-only
web server or MTA to be accessible from v4, you're going to need to make
special arrangements to do that, also.

> are v6-only and can only talk to v6-only. Is that what you want?

It's unavoidable and inherent in the fact that there are two different
address realms.  Trying to mix v4 and v6 has the same problems that
exist when trying to mix SL and globals. 

What I'm pointing out is that trying to make every application speak
both IPv4 and IPv6 is a waste of energy. It's not even possible
in general, and for many applications there are going to be inherent
biases toward either v4 or v6 - e.g. for backward compatibility
reasons, because the application inherently requires a large flat global
address space, or because the application was initially deployed in
portions of the network (e.g. the cell phone newtork, or certain parts
of the world) that were more friendly to v6 than to v4.

Keith

---

From: Ronald van der Pol <[email-masked]>
Date: Thu, 6 Feb 2003 23:21:15 +0100

On Thu, Feb 06, 2003 at 16:16:09 -0500, Keith Moore wrote:

> both IPv4 and IPv6 is a waste of energy.

I don't agree. Dual stack enables a smooth migration from v4 to v6,
but see below.

> It's not even possible

If you read my initial email again you would see that I also say that
it is perfectly OK to have IPv6-only appliances that do not need to
communicate to IPv4-only nodes.

I think dual stack is the best migration path. I also think that the
transition period should be short. Not a flag day, but also not a
transition period of decades. I agree with you that running dual
stack networks is costly *). I think the transition should be done
in a few years. I think this means the IETF should restrict new
work to IPv6-only. In other words: either move to IPv6 or abondon
the effort.

*) Dual stack is costly. ISPs have to maintain 2 number plans, 2 ACL
lists, etc. In case of problems ISPs need to figure out if it is an
IPv4-only problem, an IPv6-only problem or a problem of both stacks.
Vendors need to track IPv6-only bugs, IPv4-only bug and bugs that
exist in both protocols. When vendors introduce a new feature,
customers have to ask if the feature is supported in IPv4, in IPv6
or in both. Etcetera, etcetera.

	rvdp

---

From: Keith Moore <[email-masked]>
Date: Thu, 6 Feb 2003 17:51:13 -0500

On Thu, 6 Feb 2003 23:21:15 +0100

> I don't agree. Dual stack enables a smooth migration from v4 to v6,

Uh, no.  Not by a longshot.  For some applications (for instance, those that
do referrals) trying to support a mixture of IPv4 and IPv6 is a nightmare.

This is the sort of thing that needs to be evaluated on a per-application
basis.  Overgeneralizations such as "dual stack enables a smooth migration
from v4 to v6" are harmful.  And the assumption that both hosts are going to
upgrade to dual stack, and networks are going to support it, within a few
years, seems highly dubious.   The Internet is just too diverse to expect
everyone to migrate to v6 in the same way, and in the same timeframe.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Feb 2003 13:44:50 +0100

> On Thu, Feb 06, 2003 at 16:16:09 -0500, Keith Moore wrote:
...
> communicate to IPv4-only nodes.

And in a SOHO context or an on-board network on some kind of vehicle,
it might be very natural for those IPv6-only devices to communicate
with a local server that proxies for them in some way to the
outside world. E.g. a "building services" server that doesn't
expose individual IPv6 thermostats to the outside world, but does
expose room temperatures. That server can be dual stack.

This is to me the most natural model for really low-end devices, which 
will be very price sensitive (i.e. a few dollars difference in the cost 
of ASIC or memory really matters). Unless you want to build a NAT-PT
with a Thermostat ALG for each band of thermostat.

> in a few years.

Er, how to say this politely? "In your dreams." The only realistic
thing to plan for is an indefinite period of coexistence. Once IPv6
is seriously out there, I can't see the overlap being less than ten
years, and even that is very optimistic.

Of course, the day should come when IPv4 is an overpriced
legacy service only supported by a couple of dinosaur telcos, but
I don't expect that to happen until I'm happily retired.

> I think this means the IETF should restrict new

It's a bit soon for that. But we should clearly not accept any
WG that does stuff that isn't IPv6-ready. So IPv6 people need to
colonise every WG that exists, and read every draft for
IPv6ness.

    Brian

---

From: "Sathya Rao" <[email-masked]>
Date: Fri, 7 Feb 2003 14:26:23 +0100

I liked particularly the recommendation of Brian how IETF can make a mileage
for early deployment of IPv6.

> colonise every WG that exists, and read every draft for

Sathya

---

From: Soohong Daniel Park <[email-masked]>
Date: Mon, 10 Feb 2003 09:49:40 +0900

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ronald van der Pol
Sent: Friday, February 07, 2003 7:21 AM
To: Keith Moore
Cc: Ronald van der Pol; [email-masked]
Subject: Re: IPv6-only devices?

==>I don't agree. As I said, it will be the best not only dual stack but
also all kinds of trial toward IPv6.
      of course dual stack is simple, but don't forget some guys are
trying to make a IPv6-only in HOME.
      Isn't it a final goal to make a legacy IPv6-only ?

	Daniel

	rvdp