Subject: transition architecture discussion

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Feb 2003 17:22:19 +0200 (EET)

Hello,

There was some debate on the transition architecture wrt. the agenda for 
the next meeting.

I've sent out a short-ish (11 pages) draft to internet-drafts@ on my take 
on it.  In the meantime, it's available at:

http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-transarch-00.txt

The abstract is:

   The transition from IPv4 to IPv6 and co-existance of IPv4 and IPv6 is
   a subject of much debate.  However, the big picture of the transition
   seems not to have been discussed sufficiently.  Therefore, different
   people have different assumptions on the process, which makes
   planning the transition architecture very difficult: indeed, it seems
   that there is a lack of architecture in the transition process.  This
   memo tries to point out some issues that will need consideration in
   the transition architecture, as well as point out a few personal
   views on certain transition approaches.

.. it is by far not perfect (I didn't have any time to work on it except
the last night), and includes personal opinions (of course :-), but could
be usable as something concrete to build discussion on, if needed.

Note: I'll be off for a week beginning tomorrow.

-- 
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: Ronald van der Pol <[email-masked]>
Date: Tue, 11 Feb 2003 15:02:06 +0100

> be usable as something concrete to build discussion on, if needed.

Thanks for starting this discussion.

I think we also need to finish the scenario drafts soon (hint, hint).

It would also be useful to find out why people are not deploying/
using/requesting IPv6.

A few comments.

You restrict the architecture discussion to the "process of enabling
the use of IPv6". I don't think that's enough. I think it should
include at least the phase of a predominantly IPv6 internet. Running
dual stack is not without any costs. It is easier and cheaper to run
either v4-only or v6-only. If we don't _plan_ for a situation where
almost all traffic is v6 it won't happen.

You mention the problems of enabling IPv6 for services and bad IPv6
connectivity. That's true. I fully agree. But on the other hand
routing approved a lot when people started to use IPv6 on a daily
basis. This is just an operational issue. IPv4 networks can be
operated badly too.

Therefore, I think we should not use separate domain names (like
ipv6.example.com) or prefer A over AAAA. We (operators, not the
IETF) should put effort in v6 connectivity with the same quality
as v4.

With respect to tunneling, I think there are a couple of questions:
- Should we work on v6-in-v4 tunneling through v4 NATs (e.g. teredo)?
	I can see its use in 3GPP, where the end user does not
	have influence on the GGSN. I am not sure about home routers.
	End users have the choice to buy an IPv6 enabled home router.
- Do we have a clear tunnel architecture?
	I don't think so. We have 6to4 and configured tunnels. Is
	6to4 also for single end user systems? Do we agree on the
	security issues of 6to4? Are tunnel brokers enough? Do we
	need tsp?

Do we need to work on translation (NAT-PT, SIIT, etc)? I am not sure.
At least we should discourage it because in many cases there are
better alternatives.

	rvdp

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 11 Feb 2003 16:02:45 +0100

> It would also be useful to find out why people are not deploying/

I think the most important answer to the 'why' is simply the big
chicken and egg problem:
 - Why should an client-access provider get IPv6 when his/her/it's/...
   customers don't want (but probably do need it because of NAT).
 - Why should a hoster do IPv6 when there are no clients to use it.
 - Why should a application programmer do IPv6 when there is no
   infrastructure to use it's potential?

Combining the above with the imho bad excuse of 'bad economy' both
the hoster and the access provider won't do a thing in the right
direction.

Btw.. the application programmer has it the easiest of all, they "only"
have to modify a couple of lines of code to make their product mostly
IPv6 aware except for dialog boxes, logging, acl's and some odd
protocols.

Currently there is a nice thread (wonder o wonder) on slashdot:
http://slashdot.org/article.pl?sid=03/02/09/2038223

"IPv6 Application Competition - win $10,000"

Maybe that will take care of the third issue.
Odd part is that slashdot.org doesn't do IPv6 at all even though they
did run a couple of articles. Maybe tools like http://ipv6gate.sixxs.net
will
resolve that at least all sites are available over IPv6...

Seeing the recent jumps in TLA allocations some ISP's are on
the right way, now we only need to convince the hosters one way or
another.
Having a google that does IPv6, both the www.google.com and
localisations
and the bot would be a great leap forward.

For the rest we just need to make ISP's & hosters & programmers more
IPv6 aware...

Greets,
 Jeroen

---

From: Christian Strauf <[email-masked]>
Date: Wed, 12 Feb 2003 09:21:06 +0100

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

> I think the most important answer to the 'why' is simply the big
I think you're right. In my opinion it would be the best idea to simply create
a chicken first which then lays the eggs. :-) It probably is a good idea to
put a lot of effort into migrating most of the educational networks to IPv6 so
that new generations get used to having IPv6 arround. Maybe the convenience of
having IPv6 available during their educational phase will then also be
important later in their jobs. People usually don't want to give up things
they're used to having around. Maybe out of this motivation, the "need" for
IPv6 outside the educational sector will arise. It's easier dealing with
something that you're "brought up" with (having IPv6, that is) rather than
having to implement something completely new that you're not familiar with and
that customers also don't have an understanding of. And this will most likely
make it easier for those generations to see the advantages of IPv6 in
commercial networks (both as customers and as service providers). IMHO it is
all about IPv6 becoming a "natural" thing in the internet world.

Just my 2-EUR-cents.

Christian

-- 
JOIN - IP Version 6 in the WiN  Christian Strauf
A DFN project                   Westfaelische Wilhelms-Universitaet Muenster
http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung
Team: [email-masked]      Roentgenstrasse 9-13
Priv: [email-masked]    D-48149 Muenster / Germany
GPG-/PGP-Key-ID: 1DFAAA9A       Fon: +49 251 83 31639, Fax: +49 251 83 31653

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Feb 2003 09:35:24 +0200 (EET)

Sorry for the delay, vacation..

On Tue, 11 Feb 2003, Ronald van der Pol wrote:
[...]
> It would also be useful to find out why people are not deploying/

Indeed.  I think that for the most, it provides no added value, only
complexity and a degradation of their existing usage practises (consider 
worse IPv6 used instead of better IPv4).

I certainly use it nevertheless myself, and advocate it for 
testing/getting-used-to/pilot-deployments, but "real" uses have to wait 
for a bit, yet.
 
> include at least the phase of a predominantly IPv6 internet. 

I agree: this should be mentioned.  I just think that the "first phase", 
gaining enough momentum without hindering current IPv4 use _at all_, is 
the most important.  

There are some very usable strategies to go beyond that, but my belief is
that "we shouldn't try to run before we can walk", so to speak.

> Running
> either v4-only or v6-only. 

Yes, there are costs -- but they aren't as significant as some others,
IMO.

> If we don't _plan_ for a situation where

Well, I'm not so sure of that myself.  Something will happen when we have
enough momentum; when that happens, we have a possibility to affect how
the long-term planning will go.
 
> basis. This is just an operational issue. IPv4 networks can be

Yes -- it has gotten better, but nowhere near the levels I think I'd be 
confortable pushing IPv6 by-default to your avarage home users, for 
example.

IPv6 connectivity doesn't need to perfect (IPv4 surely isn't), but there
must not be a really significant difference, to most destinations anyway.
 
> ipv6.example.com) or prefer A over AAAA. 

This depends a lot on the transition "schedule".  If you want to do things
_now_, I would not advocate putting them to the same domain.  If you can
wait for 1-2 years and hope the connectivity is better (and after that,
notice that it actually is good enough), then you can put them in the same
names -- in 1-2 years.

Preferring A over AAAA and solutions like these provide an entirely
different deployment strategy: I'm not sure if it's a good one myself,
either -- but if we fear the stable deployment would take a long time, it
seems the only way to make (almost) everyone be safe enough to enable IPv6
out of the box.

> We (operators, not the

Totally agree here, but I'm having hard time seeing that happening .. it's 
getting better, though.
 
> 	End users have the choice to buy an IPv6 enabled home router.

As stated previously, I fear Teredo has become a hopeless effort :-(.  
However, it seems likely that NAT will remain for some time yet, so I'd
personally pursue an approach to enable bi-directional tunneling through
NAT, including heartbeating and other required features, but *no* bells
and whistles.  If the spec for this is over 10-15 pages, it's too long.

> 	security issues of 6to4? Are tunnel brokers enough? Do we

I agree the picture is not clear.  There is some resistance to the tunnel 
broker model (as well as 6to4 model, of course).  6to4 is usable for 
single end user systems, certainly.  
 
> At least we should discourage it because in many cases there are

I don't think such translation is useful in the generic case.  In some
specific cases, especially in ALG's or similar, it may be useful but
that's usually really just "data payload relaying", nothing more.