Subject: IPv6 transition architecture discussion

From: Pekka Savola <[email-masked]>
Date: Sun, 24 Nov 2002 13:44:36 +0200 (EET)

Hello,

Triggered by extended discussion at the IETF meeting on NAT-PT, I think we
should try to discuss more about the _core_ matters of the transition, for
example:

1) how to start enabling v6-capable software in the operating systems, and
having operating systems v6-enabled, in such a fashion that it does not
hinder the current usability of v4?

A starter for discussion: v6 connectivity is very poor (see
draft-savola-v6ops-6bone-mess-01 for more).  Vendors are rightfully afraid
(I sure don't want them doing it) to enable v6 by default, as connections
could easily switch to using (badly working) v6.

Do we need to do something about this or just wait N years to operators to
do something.  Note: this is a chicken-and-egg problem, ISP's don't deploy
v6 before it's requested (and paid for, in some way or another), and the
connectivity remains poor because v6 isn't really production yet.

2) are there some cases in the transition which we could ignore, to make 
it simpler?  In particular, this includes v6-only and v4-only 
interoperation.

A starter for discussion: v4-only <-> v6-only in a general case is
complex.  IMO we perhaps shouldn't try to solve the general problem, as it
draws the attention away from more important issues.  Is it ok to require
v6-only nodes will only be deployed when they don't need connectivity to
v4-only nodes (except by proxies -- e.g. TCP/UDP relay or ALG level thing
is IMO just fine)?  

For example, in home networking scenario, enabling v6-only printers etc.
should be trivial _if we require_ TCP/UDP proxy e.g. in one dual-stack
computer in the network.  On the other hand, I would imagine it could be
ok to just say, if you want to use that printer, upgrade your OS, period.

Is it required to be able to communicate between v6-only node in your
network to v4-only nodes in the general internet?  The need for this can
be mitigated by dual-stack ALG's, like web proxies. My suggestion would be
that don't deploy v6-only nodes, requiring v4 internet access, then.  
Such could still be deployed in internal networks -- most v6-only gadgets
today don't really require to be accessible or to access v4 internet
anyway -- and even v4 in the local network is also a bit arguable.

x) there are probably many other "really important" issues we need to have 
some idea of.  It's not all that useful to meddle with scenario details 
until we have some idea how the big picture should work itself out.

I think this is something we need to properly discuss now and possibly at 
the next meeting.

-- 
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: "Bound, Jim" <[email-masked]>
Date: Mon, 25 Nov 2002 11:58:06 -0500

Pekka,

I don't disagree on building scenarios, mechanisms, etc.  It is your
statements about implementations and how my product should work.  That
is where I disagree.  More below.

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Monday, November 25, 2002 3:27 AM
> To: Bound, Jim
> Cc: [email-masked]
> Subject: RE: IPv6 transition architecture discussion
> 
> 
> On Sun, 24 Nov 2002, Bound, Jim wrote:
> > > 1) how to start enabling v6-capable software in the operating
> > > systems, and having operating systems v6-enabled, in such a 
> > > fashion that it does not hinder the current usability of v4?
> > 
> > None of the IETFs business you can't tell vendors what and 
> what not to 
> > do in their products. This is not specifying standards.  You cannot 
> > tell vendors what to do with their operating systems either.
> 
> Of course, it's not IETF's business to say what to do.
> 
> But I believe it's in the interests of most of IPv6 community if we 
> develop IPv6 standards and techiques, which can be used in the most 
> non-intrusive manner suitable.

100% agree.  But not telling me what is or not enabled in my operating
system.

> 
> v6ops charter is not limited to specifying standards, I believe.

I think if you mean also Info, BCP, et al I agree if it is telling us
what our products do its not in the IETF charter let alone the v6ops
charter.

> > > draft-savola-v6ops-6bone-mess-01 for more).  Vendors are 
> > > rightfully afraid (I sure don't want them doing it) to enable 
> > > v6 by default, as connections could easily switch to using 
> > > (badly working) v6.
> > 
> > What vendor told you they are afraid?  If you cannot state 
> who that is 
> > then please retract this statement.
> 
> They haven't done the enabling yet but support is there, so 
> they're afraid.

With the chairs permission I can forward to this list a very good paper
that discusses this that is for public consumption.  If you were talking
about ISPs that is not who I was referencing.

.
> 
> > > Do we need to do something about this or just wait N years to
> > > operators to do something.  Note: this is a chicken-and-egg 
> > > problem, ISP's don't deploy v6 before it's requested (and 
> > > paid for, in some way or another), and the connectivity 
> > > remains poor because v6 isn't really production yet.
> > 
> > ISPs are deploying IPv6 you simply don't know what your 
> talking about.
> 
> You've no idea.

When you said no one is deploying IPv6 was my response.  That is not
true.  I do not dispute your hands on knowledge and did not above in my
statements.

> 
> I have 4 hats:
> 
> 1) ISP; we run a dual-stack STM-16 backbone, and believe me, 
> I think I 
> know full well about problems of ISP's
> 2) Home user; I use IPv6 at home using 6to4 etc. and have set 
> up many such 
> networks for others
> 3) Enterprise; I've designed and implemented IPv6 in several managed 
> enterprise networks, and I'm currently managing one
> 4) Vendor; I do volunteer work for a vendor and have pretty 
> much a say in 
> all IPv6-related issues
> 
> With my ISP hat on, please don't try to be authorative of 
> problems (or lack of thereof)  in ISP networks.

I never mentioned ISP network just that many of them do have IPv6 test
beds and pTLAs.  It is in process.

> 
> > Right now it is in test bed mode and that will last awhile 
> and it has 
> > nothing to do with anything we can do in the IETF to help at this 
> > point. The one thing we could do is stop wasting mail 
> messages with mail like
> > this and get some decisions made about SLs, Scenarios, et 
> al.   That is
> > the IETF's job not this diatribe you spew out here all to 
> often, that 
> > is totally irrelevant to the building of standards.
> 
> I think it's our responsibility to react if we see problems with IPv6 
> deployment.

Of course again I did not say that.  Just don't tell vendors what to do
that is all.

>  
> > > A starter for discussion: v4-only <-> v6-only in a general
> > > case is complex.  IMO we perhaps shouldn't try to solve the 
> > > general problem, as it draws the attention away from more 
> > > important issues.  Is it ok to require v6-only nodes will 
> > > only be deployed when they don't need connectivity to v4-only 
> > > nodes (except by proxies -- e.g. TCP/UDP relay or ALG level 
> > > thing is IMO just fine)?  
> > 
> > You cannot require anything Pekka.  You can only build a draft and 
> > propose a standard.  The IETF cannot mandate anything at all to the 
> > market or to those who have built and continuing to build IPv6 
> > features in products.
> 
> We have a very strong say in which standard we produce, and 
> we don't need 
> to produce more of those than we want to.

For our standards and operational statements yes.  I agree.  But above
you say the following "v6only and deployed with some type of statement
for compliance".  The IETF cannot mandate or should suggest what
customers do with their deployment.  We cannot possibly walk in
customers shoes.   That is the crux of my mail.

> > Why don't you work on
> > the scenarios as a working group member.
> 
> I believe I've contributed to all of the scenarios, it seems 
> some of them 
> are ignoring my contributions though.

That's too bad.  All participants should get a response from the design
teams.  You should complain to the chairs privately.

Have not seen any for our enterprise draft from you and would like to.

Regards,
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 25 Nov 2002 11:59:56 -0500

> > I simply disagree and strongly do not support this and ask 
> the chairs 
> > to kill 90% of what you suggest as out of scope for this 
> mail list and 
> > the IETF.
> 
> Such a reply to the perfectly reasonable and well-documented 
> draft of Pekka about the current IPv6 situation helps me to 
> understand why the IPv6 transition is so slow (I connected my 
> employer to the 6bone in 1996 and I saw very little progress 
> since). If all the IPv6 zealots believe and act the same, 
> IPv6 will stay a small island for many years to come.
> 
> If you treat such concerns like you do and with words like 
> this one, we will soon only have trolls like Dan Bernstein to 
> tell the simple truth about IPv6.

Please see reply I just sent to Pekka.  I am saying we should not tell
product developers how to deliver their products in this community it is
not our job here.

Is that better?

I fully agree we need to work on the charter of v6ops.  That does not
include making suggestions how my OS handles a printer for IPv6.

Regards,
/jim