Subject: Re: (ngtrans) On DSTM and DSTM overview

From: Juan Francisco Rodriguez Hervella <[email-masked]>
Date: Mon, 01 Jul 2002 18:19:47 +0200

Pekka Savola wrote:

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

Hello Pekka:

Why do you say that "address managment" is problematic ?
I've just installed the DSTM mechanism and it seems to work fine.

IMO, the more automatic, the better. If you want to configure manually
the IPv4-in-IPv6 tunnels and the other related stuff, you can always do it
(if
you know how to do it, of course :)

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

JFRH.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 2 Jul 2002 09:14:04 +0300 (EEST)

> I've just installed the DSTM mechanism and it seems to work fine.

DSTM model uses addresses that are configured and unconfigured 
temporarily.

I don't know your implementation, whether they've taken shortcuts or 
something, but the issue I'm mainly worried about is how the DSTM node 
decides it no longer needs IPv4 address.

One possible approach might be wait to have all applications that have 
requested IPv4 sockets close before doing that.

I worried whether this can be:
 1) done reliably (so that addresses don't get returned too early)
 2) afterwards, if address is returned, and address is requested again, 
the same one should be given
 3) the latency might be too much (when requesting a new address) if 
the address is returned too easily.
 4) practical requirement: currently it's rather difficult to avoid all 
the time using some IPv4 address (and thus requesting-returning might not 
really happen)
 
> you know how to do it, of course :)

I'm all for more automatic, but not all for more complex.

E.g. DHCPv4 over IPv4-in-IPv6 tunnels is pretty automatic and requires
nothing of address management in the node.

---

From: Octavio Medina <[email-masked]>
Date: Tue, 02 Jul 2002 12:07:47 +0200

Juan Francisco is talking about our implementation. It currently runs over
FreeBSD and makes use of RPCs over IPv6 for message exchange between the 
DSTM server/TEP and requesting nodes. You can download it from:

http://www.ipv6.rennes.enst-bretagne.fr/dstm/

My comments below:

> requested IPv4 sockets close before doing that.

This is one of the methods that have been implemented. The other one consists
in looking at the references for a route in the routing table. Whenever the
number of references comes to 0 for the default IPv4 route, the IPv4 address 
is released. 

>  1) done reliably (so that addresses don't get returned too early)

We are doing some studies to find out what is the optimal address allocation
time.

> the same one should be given

Why? If all the old IPv4 connections were closed before releasing the old
address?

> the address is returned too easily.

Depends on implementation.

> the time using some IPv4 address (and thus requesting-returning might not

Not really, if you setup ALGs (specially for http and smtp).

> nothing of address management in the node.

What is the difference between having a tunneled DHCPv4 server (How do a node 
connects to a DHCPv4 server over an IPv6-only environment?) and fixing the
allocation time of DSTM to the lifetime of requesting nodes?

Cheers,

-Octavio

---

From: Pekka Savola <[email-masked]>
Date: Wed, 3 Jul 2002 00:25:16 +0300 (EEST)

> http://www.ipv6.rennes.enst-bretagne.fr/dstm/

Ok.

> number of references comes to 0 for the default IPv4 route, the IPv4 address 

Ok.

> Why? If all the old IPv4 connections were closed before releasing the old

Perhaps the user may have signalled the address to some external entity 
(like DNS, tell his friend, ...).

But the most compelling reason is the same as with DHCP: in a production 
environment, the admins have to keep track of who had which address and 
when (e.g. consider someone performing DoS attack and after 2 days admins 
want to find out who did it).
 
> Not really, if you setup ALGs (specially for http and smtp).

Well, I guess that depends.

Many people have persistent connections, like SSH sessions, which would 
lock an IPv4 address anyway.

> connects to a DHCPv4 server over an IPv6-only environment?) 

By creating a manual/semi-automatic IPv4-in-IPv6 tunnel to some point in 
the network, like TEP.

>and fixing the

There is no need for the (new) complexity of the address management and 
withdrawal.