Subject: (ngtrans) On DSTM and DSTM overview

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Jun 2002 13:23:44 +0300 (EEST)

Hello,

A few comments.

The goal of DSTM overview document is a bit blurry.  Is it "applicability
and introduction to DSTM", something that replacement for some portions of
the DSTM specification, or what?  (Assuming the first.)

Personally I don't see why DSTM is set to solve only one specific corner 
case, ie. that nodes need a global IPv4 address; they may not have (or 
need) one even now.

I'll rephrase this by quoting my earlier comment (for which I've received 
no feedback on):

--<8--
Date: Sun, 17 Mar 2002 16:55:03 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: (ngtrans) DSTM comments

Hi,

A few comments (first time I really read the DSTM draft), so reader 
discretion is advised...

A few very generic comments:

 - I think DSTM would be useful with manual or semi-manual configuration 
too; some sites do have enough addresses (private if need be): using 
temporary addresses would just add to the complexity.  Using temp. 
addresses is valid only if the address shortage is the only reason to 
switch to IPv6..

So I think we need to consider whether we'd like to "generalize" DSTM a 
bit more: basic operation would be rather manually configured tunnels and 
such, and additional level would provide temporary addresses, automatic 
configuration of TEP and such.
[...]
--8<--

The more I think about it, the better DSTM approach becomes _IF_ 
problematic components like the addressing management is dropped out; and 
concentrate on the main issue: IPv6-only network and IPv4 tunneled over 
it.

Extra hacks for those who like DHCPv6, VPN's, temporary global IPv4 
addresses or whatnot are (more or less) useful, but should really IMO be 
options to choose from.

What do others feel about "IPv6-only network" solutions like this?

-- 
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: Octavio Medina <[email-masked]>
Date: Wed, 26 Jun 2002 11:59:39 +0200

My reply below.

> case, ie. that nodes need a global IPv4 address; they may not have (or

--->
You are right: the goal of DSTM is not ONLY to give IPv6 nodes a global
IPv4 address. It is also useful to set up IPv6-only newtowks (no native
IPv4 routing enabled) where communication in IPv4 remains possible, for example. 

> I'll rephrase this by quoting my earlier comment (for which I've received
...

> configuration of TEP and such.

--->
This can be a way to introduce DSTM. In a dual stack approach most of the
hosts need a IPv4 and an IPv6 address. If you configure manually the IPv4
you need the same amount of IPv4 addresses, but you remove IPv4 traffic on
the network.

However, manual configuration, as the name says, requires more user interaction, 
and goes against the autoconf principle of IPv6. If address shortage is not a 
problem, static v4/v6 mapping tables could be used at the DSTM server, reducing 
somehow the complexity of address allocation. In this case, DSTM nodes would ask 
only once for an IPv4 address and they will keep it permanently. The DSTM daemon 
at these nodes will take care to obtain that address, to establish a (permanent)
tunnel to the TEP and to set up the IPv4 default route towards the 4over6
interface. With this model, only little modifications will be required whenever
IPv4 addresses become a scare resource and dynamic allocation will need to be
used.

The dynamic allocation of IPv4 addresses helps to reduce the need of IPv4
to hosts that really need to use this transition mechanism. I would like to
remember that normally DSTM is not the only transition mechanism used to
migrate to IPv6. Recompilation if possible and the use of ALG will reduce
the set of applications that will need DSTM. 

In a intranet scenario, I don't think private addresses are generaly a
good choice, they can be used to exit an IPv6 cloud to reach other 
private resources.  But in the scenario described in draft-richier-dstm-vpn, 
the use of private IPv4 addresses are a good possility to access resources 
inside a domain.

> What do others feel about "IPv6-only network" solutions like this?

Thanks for your comments.

-Octavio Medina
 ENST Bretagne, Rennes
 FRANCE

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Jun 2002 13:34:54 +0300 (EEST)

Hello,

> IPv4 routing enabled) where communication in IPv4 remains possible, for example. 

Yup.  Actually an organization of less than 5000 employers but with a 
B-class address block (IPv4 /16) asked about a transition path to IPv6.

DSTM would be useful there, I think, but I really don't want to require 
the difficult parts like temporary address management; some really don't 
need it, and some are quite happy with private addresses and NAT.

> However, manual configuration, as the name says, requires more user
> interaction, and goes against the autoconf principle of IPv6. If address
> shortage is not a problem, static v4/v6 mapping tables could be used at
> the DSTM server, reducing somehow the complexity of address allocation.
> In this case, DSTM nodes would ask only once for an IPv4 address and
> they will keep it permanently. The DSTM daemon at these nodes will take
> care to obtain that address, to establish a (permanent) tunnel to the
> TEP and to set up the IPv4 default route towards the 4over6 interface.
> With this model, only little modifications will be required whenever
> IPv4 addresses become a scare resource and dynamic allocation will need
> to be used.

Note that IMO, "manual configuration" is relative.  DHCPv4 can be used for 
address management.  The tunnels could be managed with a small script or 
program, and the TEP found using a DNS lookup.  "Manual" can be quite 
friendly with the IPv6 autoconf model.
 
> the set of applications that will need DSTM. 

Yes.
 
> the use of private IPv4 addresses are a good possility to access resources 

Very extensive deployments show that people seem to be quite happy with 
private addresses + NAT, so I guess they will be used in the future too.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Jun 2002 13:38:58 +0300 (EEST)

a minor correction

> Yup.  Actually an organization of less than 5000 employers but with a 

employees of course :-)