Subject: RE: WG Review: IPv6 Operations (v6ops)

From: "Bound, Jim" <[email-masked]>
Date: Thu, 5 Sep 2002 09:42:18 -0400

Pekka,

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Thursday, September 05, 2002 7:31 AM
> To: Bound, Jim
> Cc: Jun-ichiro itojun Hagino; Brian E Carpenter; Fred L. Templin;
> [email-masked]
> Subject: RE: WG Review: IPv6 Operations (v6ops) 
> 
> 
> On Wed, 4 Sep 2002, Bound, Jim wrote:
> > I don't hear that from any user in that way.  What I hear 
> is there are
> > several good mechanisms they like and want to apply for different
> > reasons.
> 
> For (over?) 95% of folks, they're just distraction.  And what 
> we want here
> is to get deployments going.  There's little need for 
> anything fancy if
> you don't require it. 

Deployment is going as best it can right now.  See the NTT MSC announcment that came out yesterday in Malaysia that is native IPv6.  I don't think ISATAP, DSTM, or Teredo are "fancy" but solid mechanisms that work and for those moving at very fast pace.

The mechanisms I feel are imperative for wide deployment are as follows:

Basic Tunnels
6to4
ISATAP
Teredo
DSTM
BIA (in some cases but caution is needed)

NAT-PT and SIIT should be last resort and not used unless there is no choice.

So not including NAT-PT and SIIT above that is 6 mechanisms.  That is not to much for any user I know to absorb and understand.   They are all deployed and implemented and all will work and all together as package permit users to adopt IPv6 without the use of Network Address Translation.  Teredo though there are many parts is very doable on the Intranet, Extranet, and Internet.  It will work.  

DSTM+ISATAP+Teredo+6to4 have multiple combinations also where they can work together.

I see two key areas of deployment where there is real money to be made for IPv6.

One is where technology is being built for military operations with IPv6 and many of what is called the Intelligent War Fighter visions will not even use IPv4 for things like sensor devices and other things I won't get into.  They are in the factory now being built for 4 years from now.  Using anything with IPv4 as core is a non-starter.
Sure there will be legacy IPv4 things to speak with but thats where ISATAP and DSTM come in but not 6to4 or Teredo.

The other is Mobile IPv6.  Mobile IPv4 simply will not work except on an Intranet because anywhere NAT exists it kills true roaming without a "reconnect".  Mobile IPv6 handsets require IPv6 and if they need IPv4 it is temporary because like the NTT MSC case all the initial services for the user are hosted with IPv6 like Web, Database, etc.

What is happening is that unless vendors, operators, and some other entities I won't mention begin to make money on IPv6 they are going to stop momentum.  Fortuneately we are seeing real purchase orders for IPv6 and boxes and software be sold at significant levels to warrant continued engineering and market investments. But those returns are not from the large mass that will move with LCD mechanisms or the 80% that will do as you say and want universal solutions (as Brian suggested).

So the catch-22 is that the 20% of custom users is where we will all make our money for the next 3 years.  Then the masses will begin conversion.  So my issue is that to stop work on what we are doing that will make money is crazy in the IETF.  Maybe we need an advanced Ipv6 transition area as Brian suggested but if that don't happen fast the vendors and entities that want to deploy this 20% will not wait for the IETF and do it out of band and create a storm of defacto standards for IPv6 that will compete with the IETF in the market.  They have no choice and will not loose the mony waiting on 2 and 3 year discussions of how to do transition or settle for universal compromised solutions.

> 
> I don't think all of these non-basic, complex, fringe(?) 
> mechanisms should
> be discarded -- quite the contrary.  But this is probably(?) 
> not the right 
> place.

I am not sure yet.  Randy Bush has been saying IPv6 is here as operator and I agree. How IPv6 deploy is still TBD.  Why should not this true 20% deployment sector recieve the work from v6ops effort?  I think not doing it is not wise.

> 
> Waiting for nice mechanism "X" is also a good excuse to delay 
> transition
> btw.

No one has to wait.  They are defined and done.

> 
> > Also the one we are missing in our thinking is the user who 
> will deploy
> > a dominant IPv6 backbone where the only access to IPv4 is simply to
> > reach legacy systems.  They are also the ones deploying trial Mobile
> > IPv6 networks with Mobile IPv6 handhelds.  For them Ipv4 is to be
> > treated as-needed basis.  They don't even want to use 6to4. 
>  They will
>           ^^^^^^^^^^^^^^^
> > use ISATAP to jump-start installed base.  They will use 
> DSTM to give out
> > addresses in ad-hoc manner.  [...]
>                ^^^^^^^^^^^^^
> 
> I could say probably over 99% of folks doing this are not living in 
> today's world.

This is simply not true I hope my above mail helps change your mind on this statement above as its as far as I can take to convince you and others.  

> 
> IPv4 just isn't ready to be "as-needed" at the moment, or 
> you're probably
> using it in very simple ways (e.g. www browsing only which works quite
> well with NAT too :-).  It's IMO very questionable to approach IPv4 
> needs with an "ad-hoc" ways when clearly the requirements for 
> IPv4 are 
> not, in reality, ad-hoc.

Ad hoc means the use of IPv4 is dicouraged as a policy and used only when necessary.  So maybe adhoc was wrong term on my part.

Many users want to run at 1000 miles an hour away from IPv4 NAT it is hurting them bad to evolve their networks for true peer-to-peer computing, applications, and security.
That is driving the 20% above strongly to native IPv6 and dominant IPv6 strategy.

> 
> But this is one approach for enterprise transition.  I've 
> been asked about
> it myself a few times: organization which would want to start 
> deploying
> IPv6 internally, perhaps do some translation or proxying to reach IPv4
> sites and just wait for an usable IPv6 Internet to emerge in 
> xxx years.
> The problem with this is, really, that unless you can 
> convince (lie :-)  
> very well that xxx is not much more than 1-2, IS managers discard this
> approach as it generates no added value in the short term.  Most don't
> want to be the test-bunnies for fancy technology.

When there future business depends on IPv6 test bunnies are easy to be and that is exactly what is happening now. 

> 
> > But the key missing point in our collective thinking is 
> assuming this
> > type of network for IPv6 will only happen later during IPv6 
> adoption.  
> > That is plain wrong.  Many of the users of IPv6 are building new and
> > emerging systems that will be IPv6 out of the box and the 
> networks for
> > first deployment.
> 
> I'd like to see this on real world (and not on fancy .ppt).  
> People always
> seem to forget that they do happen to need IPv4 for something 
> (e.g. in the
> case of routers, SNMP monitoring, RADIUS authentication for 
> logins etc.)

That is being done right now within the 20% and entire architectures are being reworked to do exactly what I say above at some pretty significant levels within the enties with Exec VP support.  Ipv6 is necessary now Pekka not an option.  Its is not a question of "if" but "when".  

regards,
/jim

>  
> -- 
> 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: Pekka Savola <[email-masked]>
Date: Sun, 8 Sep 2002 20:14:23 +0300 (EEST)

Hello,

Getting back to a few points.

On Thu, 5 Sep 2002, Bound, Jim wrote:
> Deployment is going as best it can right now.  See the NTT MSC
> announcment that came out yesterday in Malaysia that is native IPv6.  

Native IPv6 is the proper and easy way.  The press release does not 
elaborate on the tunneling mechanisms used though.  And there's nothing to 
suggest v6-only (which was one of my "not of this world" arguments) there.

> I
> don't think ISATAP, DSTM, or Teredo are "fancy" but solid mechanisms
> that work and for those moving at very fast pace.

Some are more useful than others.  I suppose they work, more or less, in
more or less restricted topologies.  I have doubts about the stability in
the long term or when more people would start to use them.
 
> The mechanisms I feel are imperative for wide deployment are as follows:

Sure.

> ISATAP

May be useful in some scenarios (IMO, especially large enterprises with 
slow and sparse deployment or a lot of internal traffic).

> Teredo

Have you read the latest versions of the draft?  It's a patch over a patch
over a patch against (mis)features of NAT (not a fault of the author of
course).  It's just too complex to work reliably.

I would rephrase this as:

"Some reliable and simple mechanism to provide v6 behind a NAT"

(Yes, it's possible -- but there are some engineering tradeoffs!)

> DSTM

I'm not yet convinced of this.  Especially I have huge doubts about 
temporary address management scalability and robustness.

> BIA (in some cases but caution is needed)

May be useful for legacy apps, yes.
 
> NAT-PT and SIIT should be last resort and not used unless there is no choice.

Agreed.
 
> What is happening is that unless vendors, operators, and some other
> entities I won't mention begin to make money on IPv6 they are going to
> stop momentum.  Fortuneately we are seeing real purchase orders for IPv6
> and boxes and software be sold at significant levels to warrant
> continued engineering and market investments. But those returns are not
> from the large mass that will move with LCD mechanisms or the 80% that
> will do as you say and want universal solutions (as Brian suggested).
> 
> So the catch-22 is that the 20% of custom users is where we will all
> make our money for the next 3 years.  Then the masses will begin
> conversion.  So my issue is that to stop work on what we are doing that
> will make money is crazy in the IETF.  Maybe we need an advanced Ipv6
> transition area as Brian suggested but if that don't happen fast the
> vendors and entities that want to deploy this 20% will not wait for the
> IETF and do it out of band and create a storm of defacto standards for
> IPv6 that will compete with the IETF in the market.  They have no choice
> and will not loose the mony waiting on 2 and 3 year discussions of how
> to do transition or settle for universal compromised solutions.

But are those 20% of users such that they *need* a "custom" transition 
mechanism?  Why not e.g. consulting them how to build their network using 
current mechanisms?

> I am not sure yet.  Randy Bush has been saying IPv6 is here as operator
> and I agree. How IPv6 deploy is still TBD.  Why should not this true 20%
> deployment sector recieve the work from v6ops effort?  I think not doing
> it is not wise.

Randy Bush has a network/ISP operator background AFAIK.  Deploying IPv6 
there is a much more simple task than deploying it properly in 
organizations.

There's much more to 'IPv6 is here' than having it enabled on dual-stack
routers.

> This is simply not true I hope my above mail helps change your mind on
> this statement above as its as far as I can take to convince you and
> others.

See comment above, I don't think v6-only is really here yet.
> Ad hoc means the use of IPv4 is dicouraged as a policy and used only
> when necessary.  So maybe adhoc was wrong term on my part.

And if it's necessary for a node to use it, 10, 100, 1000 times a day?  Is 
Ad-hoc really the best way to go?

---

From: Francis Dupont <[email-masked]>
Date: Mon, 09 Sep 2002 15:06:33 +0200

Sure.
   
=> I am not convinced by 6to4. For instance by the 6to4-relay concept.

   
=> this address management is exactly the current DHCPv4 address management
(I agree this is not a real answer :-).

=> the problem for an ISP is not the task, it is the business...

Regards

[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Mon, 9 Sep 2002 23:43:45 +0300 (EEST)

> => I am not convinced by 6to4. For instance by the 6to4-relay concept.

6to4 relays cause some rather interesting problems, especially relating to 
quality of service (too few of them at the moment, leading to huge 
delays connecting to 6to4 nodes from some areas).

> (I agree this is not a real answer :-).

No it *definitely* isn't, or I've misunderstood the intent.  What has been
proposed is something like 'when application requests and address, get it
from somewhere, after application exists, return it'.  That's very far
from DHCPv4.  Add the ports option to the stew and you have a mess..

Running DHCPv4 over DSTM (with reasonable address lifetimes etc.) would
sound much better than currently proposed.

---

From: Rob Austein <[email-masked]>
Date: Mon, 09 Sep 2002 17:14:54 -0400

> delays connecting to 6to4 nodes from some areas).

Once upon a time we used routing protocols to handle problems that
were at least superficially similar to this.

> sound much better than currently proposed.

Damn, that's so simple even ordinary users might understand it :).

---

From: Francis Dupont <[email-masked]>
Date: Tue, 10 Sep 2002 13:06:03 +0200

=> I had more security issues in mind...

   > (I agree this is not a real answer :-).
   
   No it *definitely* isn't, or I've misunderstood the intent.

=> IMHO the second (:-).

   What has been
   proposed is something like 'when application requests and address, get it
   from somewhere, after application exists, return it'.

=> no, the address is renew if it is still in used and it is returned
after a delay (i.e., one checks from time to time if it is used and
returns it if not. Of course the initial delay is greater).

   Add the ports option to the stew and you have a mess..

=> I don't like the ports option (too close to NAT).

=> I believe you have misunderstood the proposal: it works exactly like
DHCPv4, the only difference is the allocation (request) is done only
when needed, not a priori. And in our implementation the allocation
control is performed by a reused DHCPv4 code...

Regards

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Sep 2002 16:27:12 +0200

>    delays connecting to 6to4 nodes from some areas).

If the worst problem with 6to4 is already a purely operational one,
I'm not at all distressed, and I wonder whether we can encourage
all XPs to operate a 6to4 relay?

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Sep 2002 16:30:15 +0200

>  In your previous mail you wrote:
...
> => I had more security issues in mind...

I would like this WG to consider draft-savola-ngtrans-6to4-security-01.txt
as the basis for a possible work item.

   Brian

---

From: Francis Dupont <[email-masked]>
Date: Tue, 10 Sep 2002 16:48:13 +0200

=> some clarifications:

   >    > => I am not convinced by 6to4. For instance by the 6to4-relay concept.

=> my comment.

   >    delays connecting to 6to4 nodes from some areas).
   
=> Pekka's comment (the answer to mine).

      Brian
   
Thanks

---

From: Randy Bush <[email-masked]>
Date: Tue, 10 Sep 2002 07:58:37 -0700

> I'm not at all distressed

aaaaiiiiiiiiiiiiiiiiii!

---

From: Pekka Savola <[email-masked]>
Date: Tue, 10 Sep 2002 21:15:28 +0300 (EEST)

> all XPs to operate a 6to4 relay?

I wonder if we can encourage Microsoft implementations not to assume bogus 
things about 6to4 relays.  Like it having the address 
'2002:<RELAY_IPv4>::<RELAY_IPv4>'.

---

From: Robert Elz <[email-masked]>
Date: Wed, 11 Sep 2002 15:50:27 +0700

Date:        Tue, 10 Sep 2002 21:15:28 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | I wonder if we can encourage Microsoft implementations not to assume bogus 
  | things about 6to4 relays.  Like it having the address 
  | '2002:<RELAY_IPv4>::<RELAY_IPv4>'.

I haven't seen the implementation, so this is a real question ... which
way is it assuming that?

If when it is acting as a 6to4, that's the address it assigns itself,
that is, RELAY_IPv4 is its own IPv4 address, then that sounds OK to me,
it has to have something, as a v6 addr by default, right?

If it is assuming that some other node will have that address, then why?
Why would anyone ever want to directly address a 6to4 relay node?  That
would be much like having nodes attempt to guess the IP(4 or 6) address of
some router along the path to a destination (including the local egress
and remote ingress routers).   It just makes no sense to assume anything
about any of those addresses (I mean, how would you even tell it was
making the assumption).

So, what is the actual encouragement that is needed?

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Sep 2002 10:51:58 +0200

> '2002:<RELAY_IPv4>::<RELAY_IPv4>'.

The specification that the IETF actually approved was for router-based
6to4, not host-based, and it was assumed that router operators would
club together to configure and share relays. Clearly, a client-host 
based implementation such as the one you mention leads to quite different 
issues around relay deployment, which were not considered in the original 
scenario. We are still missing an RFC really analysing host-based 6to4,
and until that work has been done we don't know what is bogus.

   Brian

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Sep 2002 10:57:51 +0200

We are still missing an RFC really analysing host-based 6to4,
   and until that work has been done we don't know what is bogus.
   
=> a new work item for the v6ops WG?

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 11 Sep 2002 18:03:10 +0900

>club together to configure and share relays. Clearly, a client-host 

	WinXP node can become a router, so there's nothing prohibiting WinXP
	from running 6to4.  in fact, i don't see any distinction between
	"router-based 6to4" and "host-based 6to4" in the RFC.  am i mistaken?

itojun

---

From: Pekka Savola <[email-masked]>
Date: Wed, 11 Sep 2002 12:35:01 +0300 (EEST)

Perhaps I should have been more clear, sorry.

> it has to have something, as a v6 addr by default, right?

What I meant is that 6to4 routers, in MS implementations that I'm aware
of, can be configured with the relay's IPv4 address.  Additionally it's
looked up from DNS.  No problem.

For MS implementation to be able to use that specified relay, the relay
must have 2002:<RELAY_IPv4>::<RELAY_IPv4> address.  (I assume it's trying
to ping the relay before using it or something, I really don't care that
much).

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 Sep 2002 03:59:41 -0700

> a new work item for the v6ops WG?

how is this different from what shipworm is trying to solve?

randy

---

From: Rob Austein <[email-masked]>
Date: Wed, 11 Sep 2002 13:51:43 -0400

> how is this different from what shipworm is trying to solve?

Shipworm has a lower required density of global IPv4 addresses;
host-based-6to4 has less reliance on middleboxes.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Sep 2002 15:06:12 +0200

From the Introduction to RFC 3056:

>    The basic mechanism described in the present document, which applies
>    to sites rather than individual hosts, will scale indefinitely by
>    limiting the number of sites served by a given relay router (see
>    Section 5.2).  It will introduce no new entries in the IPv4 routing
>    table, and exactly one new entry in the native IPv6 routing table
>    (see Section 5.10).
> 
>    Although the mechanism is specified for an IPv6 site, it can equally
>    be applied to an individual IPv6 host or very small site, as long as
>    it has at least one globally unique IPv4 address.  However, the
>    latter case raises serious scaling issues which are the subject of
>    further study [SCALE].

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Sep 2002 15:14:32 +0200

> host-based-6to4 has less reliance on middleboxes.

Also (this is what Jim's reply was getting at too), 6to4 assumes
that it is implemented *in* a router (or NAT/router) whereas Teredo
assumes it has to traverse an uncooperative NAT.

6to4 simply fails if it is *behind* a NAT. It wasn't aimed
at that scenario. It wasn't designed as a host solution, so
NAT traversal was not a requirement. So when you hammer 6to4
into a host, there are cases where it simply cannot work.

   Brian

     Brian

---

From: Keith Moore <[email-masked]>
Date: Thu, 12 Sep 2002 09:49:36 -0400

> So when you hammer 6to4

I use 6to4 on hosts every day, so I don't consider it hammering.

But 6to4 was primariliy intended for routers.  That it happens
to work on some hosts is a happy side-benefit, not the design goal.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Sep 2002 17:19:56 +0200

> to work on some hosts is a happy side-benefit, not the design goal.

Indeed. 

   Brian