RE: IPv6 transition architecture discussion

[Pekka Savola <pekkas@netcore.fi>]

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.

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

> > 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.
> 
> 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.
 
> All vendors shipping products have web pages and kits to install IPv6.

I didn't dispute this, and it wasn't the point.

> You might go buy them and test them for yourself.  Also all our
> interoperability labs are doing this now UNH, ETSI, TAHI, and now China.
> This is none of the IETFs businss or v6ops unless that works points to a
> protocol or operations problem on the network.  If you know of such
> cases I am sure the chairs would love to hear them.

I already pointed out the operational problem here.

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

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.

> 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.
 
> > 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 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.
> 
> You have to be kidding right?   Have you ever shipped a product that a
> customer is using?  If so you should know that no one in this standards
> body or any standards body or even any deployment forum (which has far
> more influence and power than the IETF to affect deployment) will EVER
> tell a vendors customer what to do with their OS.   This is silliness
> and borders on outright confusion on your role in the IETF and the role
> the IETF will support you in.  This will not happen here.

We have the right to restrict our focus if we believe that's the best
thing to do.  Of course, we can't forbid people from doing something, but
we may document the way our proposed solution will work out.

> > 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.
> 
> Then right a spec for transition.  I would hope the chairs tell you to
> wait for the scenarios as everyone else is told. 

There are fundamental issues which affect all the transition scenarios.  
I believe we should try to figure out some answers to those; this is what
I noted in the meeting when the NAT-PT discussion turned to IMO critical
core issues.

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

Waiting for next revisions of the documents so I can keep on 
contributing...

> > 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.
> 
> What your asking is the kind of discussions one has when building
> products.  But I don't agree and the chairs have made it pretty clear we
> must work on scenarios.  I have come to support that and it makes some
> logical sense.   The scenarios are about use cases and people deploying
> now and that is the big picture.

Some people have already deployed and noticed problems.

We need to make deployment scenarios that will work.

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