Subject: WGLC ent-analysis-03: DSTM

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Aug 2005 22:47:18 +0300 (EEST)

Hi,

(I'll put two most separable & possibly most discussable items in 
separate mails.)

In 8.1:

  Later in the transition process, after the enterprise has
  transitioned to a predominately IPv6 infrastructure, the architect
  should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or
  in the case of early deployment of IPv6-dominant networks DSTM can
  be used too.

and in 8.4:

DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the
enterprise transition or deployment of IPv6-dominant network links
is desired. DSTM is to being submitted as an IETF Experimental RFC.

==> as it is, DSTM is a way too overloaded a mechanism to be referred to
without more disclaimers or description.  As it is, different people use
"DSTM" to mean at least the following things:
  a) v4-in-v6 tunnels
  b) automatically set-up v4-in-v6 tunnels
  c) automatic set up of v4-in-v6 tunnels when the host
     doesn't have v4 address and an app wants to create a v4 socket
  d) automatic monitoring and tear-down of said v4-over-v6 tunnel
     when the host detects it no longer needs the address/connectivity
  e) plus a number of extensions for even more colorful setups.

a) doesn't require DSTM; b) can be achieved using a tunnel broker; c)
does not require IETF interoperability (a local implementation choice
when/how to launch the v4-in-v6 activation).  d) could also be considered in
the same category (there are no bits in the wire or anything requiring
interoperability AFAICS on when the host removes the tunnel), though I'm
skeptical whether even providing that would be a good engineering choice.

My point is that I'm having hard time figuring out:
  1) what the document means when it's recommending DSTM, and
  2) based on my analysis above, I do not believe that DSTM (in the way that
     I think it's being referred to) is even needed.

Therefore my suggestion is to remove references to DSTM (preferable) or
greatly clarify the assumptions and the requirements on why it should
be necessary. (On the other hand, if the DSTM spec only described the
algorithms for doing c) and d) above in my list, I would have a lot fewer
concerns -- but as it is, I believe a reference would confuse more than
help.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Francis Dupont <[email-masked]>
Date: Wed, 17 Aug 2005 10:04:14 +0200

In your previous mail you wrote:

   and in 8.4:

   ==> as it is, DSTM is a way too overloaded a mechanism to be referred to
   without more disclaimers or description.

=> the overload (if any) should be solved by the references...

    As it is, different people use
   "DSTM" to mean at least the following things:

=> I saw the birth of DSTM: DSTM is Jim Bound's AIIH + Laurent Toutain's DTI.

     a) v4-in-v6 tunnels

=> this (b-a) is DTI

=> this (c-b) is AIIH

=> this (d-c) is an operational consequence of AIIH.

=> I believe you mean DSTM+

   a) doesn't require DSTM;

=> I agree, there are 3 kinds of tunnel interface:
 - static (the state is per interface)
 - dynamic (the state is in a table, one interface is enough to handle
   many tunnels. Note this is implementation)
 - algo (the state (end-point addresses) is taken from the packet
   (inner addresses). An example is 6to4)
DTI is exactly the dynamic flavour and is needed in DSTM for scalable
Tunnel End-Points.

   b) can be achieved using a tunnel broker;

=> this is both true and false: how the state is managed can be orthogonal
to the tunnel interface itself.
BTW the point is critical for the interoperability.

   c) does not require IETF interoperability (a local implementation choice
   when/how to launch the v4-in-v6 activation).

=> I don't understand your comment: the idea (AIIH) is more than useful
when a global IPv4 address is required.
PS: AIIH is the by-need allocation of an IPv4 address.

   d) could also be considered in
   the same category (there are no bits in the wire or anything requiring
   interoperability AFAICS on when the host removes the tunnel), though I'm
   skeptical whether even providing that would be a good engineering choice.
   
=> d is a consequence of the possible allocation of global IPv4 addresses
and is managed exactly as DHCPv4 does. To compare with similar mechanisms,
IKEv2 CFG_REQUEST can allocate home IPv4 addresses with expire/renew/...

=> the references

     2) based on my analysis above, I do not believe that DSTM (in the way
     that I think it's being referred to) is even needed.

=> DTI is needed as soon as the TEP has to be scalable, AIIH is needed
as soon as global IPv4 addresses are needed. Note that extra capabilities
should not be a problem, i.e., DSTM works well with static IPv4 addresses,
and even when they are not needed they can bring some advantages, exactly
as DHCPv4 can be used as a management tool where it only gives static
addresses (aka BOOTP mode).
   
Regards

[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Aug 2005 12:51:46 +0300 (EEST)

First off (after writing the response below), let me clarify the list 
of v4-in-v6 tunnel functions:

As it is, different people use "DSTM" to mean at least the following 
things:

  a) (manually configured) v4-in-v6 tunnels [RFC2473]

  b.1) the set-up of the bidirectional v4-in-v6 tunnel with the tunnel
     server(s) which can happen without user intervention, e.g., using
     one of the processes described in draft-palet-v6ops-tun-auto-disc-03.txt.
     This must include a way to auto-configure a v4 address [e.g., DHCPv4].

  b.2)  the automatic set-up of v4-in-v6 tunnels, so that between each
     host, an ad-hoc tunnel can be signalled and set up" [6to4-like
     traffic optimization]

  c) assignment of an address on top of v4-in-v6 tunnel(s), but
     deferred until the application wants to create v4 socket.
     [issues with dual-stack server apps, for example]

  d) automatic monitoring and tear-down of said v4-over-v6 tunnel(s)
     when the host detects it no longer needs the address/connectivity

  e) plus a number of extensions for even more colorful setups (e.g.,
     instead of just assigning an address, assign only certain _ports_
     of an address).

Personally,
  - I believe there is a need for a) [but that's already specified];
  - I think there also is a need (now or in the future) for b.1).
  - b.2) does not seem to be a good way to go (if traffic 
optimization is needed, maybe you shouldn't be using tunneling in the 
first place or you should deploy more tunnel servers and make _them_ 
interconnected).
  - c) is something implementations may try to do on their own, but I 
would recommend against it, and the IETF shouldn't work on that
  - d) doesn't seem to be worth the effort and is probably difficult to 
get right -- and for addresses, DHCPv4 and other methods already 
exist; not sure we want/need to do more work on that.

I have no problem having the enterprise analysis document include this 
kind of analysis, and describe the need for a) and b.1) -- and I think 
this is probably a good thing as it might lessen the confusion on the 
real requirements for v4-in-v6 tunnels -- but if we go further than 
that, we may have a problem....

More inline..

> => the overload (if any) should be solved by the references...

This is a working group document.  I don't think we can just refer to 
a non-wg, ambiguous document and expect it to clear up the ambiguities 
and confusion.

> => I saw the birth of DSTM: DSTM is Jim Bound's AIIH + Laurent Toutain's DTI.

That may be, but many people since have used the term, and may have 
zero idea what the goals are or may have been.

>     b) automatically set-up v4-in-v6 tunnels

Based on later messages, I think you misunderstood what I tried to 
refer to with b).

What I meant was like,

      "b.1) the set-up of the bidirectional v4-in-v6 tunnel with the 
tunnel server can happen automatically, e.g., using one of the 
processes described in draft-palet-v6ops-tun-auto-disc-03.txt"

But what I think you took it to mean was,

      "b.2) the automatic set-up of v4-in-v6 tunnels, so that between 
each host (and/or tunnel server), an ad-hoc tunnel can be signalled 
and set up" [6to4-like traffic optimization]

Is this correct?

I was certainly referring to b.1) only.

>        doesn't have v4 address and an app wants to create a v4 socket
[...]
> BTW the point is critical for the interoperability.

Certainly, if you wanted to create ad-hoc tunnels (6to4-like) between 
each host or the like, a protocol interoperability that goes beyond 
the plain tunnel broker would be needed.  But I wasn't implying that 
functionality (nor do I think it is needed).

> PS: AIIH is the by-need allocation of an IPv4 address.

What I meant is that if you already have a) and b.1), i.e., an ability 
for the host to set up a tunnel without manual configuration with a 
tunnel server, all your implementation needs to do is add a hack which 
triggers this activation when the v4 socket call is being made.

There is no difference between b.1) and c) wrt. bits on the wire, 
right?

> IKEv2 CFG_REQUEST can allocate home IPv4 addresses with expire/renew/...

But if we can already use exactly DHCPv4 on top of the tunnel, why do 
we need to do anything?  If DHCPv4 supports address dynamicity, the 
only thing left is whether you need to signal the teardown of the 
tunnel... and that seems hardly sufficiently useful.

>     1) what the document means when it's recommending DSTM, and

As said, I don't think a wg doc like this can shrug off these kinds of 
issues by just referring to non-wg documents and letting them sort 
things out.  Best would probably be summarizing the different 
requirements or non-requirements (a-d above) in this doc, removing the 
references altogether, and enhancing the dstm spec (or writing a 
separate draft describing the scenarios/requirements for v4-in-v6 
tunneling) to try to remove any confusion.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 19 Aug 2005 15:15:57 +0200

b.1) the set-up of the bidirectional v4-in-v6 tunnel with the tunnel
        server(s) which can happen without user intervention, e.g., using
        one of the processes described in
        draft-palet-v6ops-tun-auto-disc-03.txt.

=> note this I-D was submitted years after DSTM and is not a complete
solution (in fact, today it is not a solution at all :-).

=> I believe you mean something providing the same service than DHCPv4,
not DHCPv4 itself.

=> I believe you have "direct tunnels" in the b.2 idea?

=> note that c) is needed if allocated IPv4 addresses are global.
To come back to the DHCPv4 analogy, with DHCPv4 an address is needed
when a node attaches to the network, with c) an address is need
when (and only when) a node has to make an IPv4 communication.

=> as I've already explained, d) is a consequence of c).

   Personally,

=> I agree: traffic optimization is not the problem to solve.

=> c) is *not* an option when you have not one address per node, i.e.,
when b.1) is not usable.

=> perhaps I have misunderstood d) but when the IPv4 address expires the
tunnel must be torn down...

=> we have already a problem with IPv4 global addresses: there are not
enough!

   
=> so your concerns are about the DSTM documents?

   > => I saw the birth of DSTM: DSTM is Jim Bound's AIIH + Laurent
   
   That may be, but many people since have used the term,

=> the term is not (yet :-) a trade mark...

   and may have zero idea what the goals are or may have been.

=> this is a random remark which is not about the WG I-D.

   
=> I refer to the b-1 tunnel mechanism only (not the way to setup them).

=> what I said is the setup mechanism is orthogonal to the tunnel
mechanism and the only thing about it is just to have one (zero
doesn't work, two or more don't interoperate). BTW to be clearer
here I mean the setup of a tunnel between a node and a TEP.

   
=> the difference between b.1) and c) is the type of IPv4 addresses.
If the IPv4 address can be statically allocated c) (and in fact b.1) too)
is not required, if the IPv4 address is global and cannot be statically
allocated (because the pool is too small), c) is required (and d) as
a consequence of c) too). BTW you could say that a NAT removes the
requirement but I don't think you'd like to use this argument.

   > IKEv2 CFG_REQUEST can allocate home IPv4 addresses with expire/renew/...
   
   But if we can already use exactly DHCPv4 on top of the tunnel,

=> we can't...

   why do we need to do anything?  If DHCPv4 supports address dynamicity,
   the  only thing left is whether you need to signal the teardown of the 
   tunnel... and that seems hardly sufficiently useful.
   
=> you make the false assumption DHCPv4 itself can be run over the tunnel.

   
=> so you ask for a scenario with global IPv4 addresses (c)) or
for clear operational advantages for (c)).
IPv6-dominant networks (section 6) are the reason to ask for at least a),
the text ("must acquire...locate...") suggests at least b.1).
It seems I have now a clear view of the "missing part" in the WG I-D...
I propose this scenario:
 - an IPv4 site with 200 nodes using a /24 is connected to the Internet.
 - the site grows to 500 nodes, solutions are:
   * get more IPv4 addresses: I suppose it is not possible.
   * put a NAT: I suppose we don't want this!
     Note a NAT on addresses only should be enough.
   * switch to IPv6, get a /48, take advantages of IPv6 feature, etc,
    but what to do with partners (perhaps including the ISP :-) still
    using IPv4: lookup for the solution in the WG I-D?
 - I assume there is a reasonnable number of "simultaneous" nodes which
   need an IPv4 address from the /24 pool. This assumption is used for
   the NAT or the DSTM solution (I have real world figures to support
   this assumption).
 - the best solution is DSTM...

Regards

PS (for authors): BTW the right spelling of IPsec is IPsec (cf RFC2401bis).

---

From: Pekka Savola <[email-masked]>
Date: Mon, 22 Aug 2005 13:10:43 +0300 (EEST)

> solution (in fact, today it is not a solution at all :-).

Within an enterprise network (and having to discover v4-in-v6 TEP, so 
NATs are not an issue), the problem is much more constrained, so e.g., 
DHCPv6 is a possible solution.  Softwires BOF might do something about 
this, or maybe not -- if folks are interested in this kind of problem, 
maybe they should speak up at a forum.  In any case, the same 
approaches as are available for "DSTM" are probably also applicable 
here.

> => I believe you mean something providing the same service than DHCPv4,

While DHCPv4 may or may not require minor tweaks (e.g., relating to 
link-layer adaptation), I think it could basically be used itself, 
and for the service.  Could you elaborate why you think it's 
inappropriate?

> => I believe you have "direct tunnels" in the b.2 idea?

Yes.

> when (and only when) a node has to make an IPv4 communication.

No, "global v4 addresses -> c)" does not follow.

It is a perfectly fine way to run and use addresses to give each node 
requiring v4 connectivity a static global address.  Those which need 
them only now and then can also use global addresses, but the easiest 
would probably be using RFC1918 for those nodes.

The issue how aggressively to conserve v4 address space at the cost of 
more complexity and mechanisms like dynamic assignments/removals is a 
trade-off.  Some may believe it's worth the effort; many others (like 
me) think it's not (and personally, I think it'll cause more harm than 
help).

I gave further reasons for my belief in my reply to Stig on Aug 10, 
with subject "Re: Enterprise Analysis DSTM Issue: dynamic setup", 
especially wrt. who needs a global or private address.

> => as I've already explained, d) is a consequence of c).

While d) may be desirable by some if you want to release the global 
address back to the "pool" as soon as possible, it's not a direct 
consequence AFAICS.  It'd be perfectly fine to deploy only c) with the 
assumption that if the host needs v4 even once, it gets v4 "for good" 
(at least as long as isn't rebooted).

While c) may not conserve address space as effectively as c)+d), it's 
something to be evaluated based on the tradeoffs.

> => c) is *not* an option when you have not one address per node, i.e.,

I'm not sure what you meant with "is *not* an option".  What is the 
option then?

> tunnel must be torn down...

No, I don't think it follows.  I don't see why you couldn't just have 
a v4-in-v6 tunnel but the host wouldn't have any v4 address, right?

An analogue: when my DSL provider's DHCPv4 server goes down or the DSL 
modem's DHCP snooping breaks, my lease expires and on my BSD router 
the public v4 address I normally have is changed to "0.0.0.0".  If I 
re-run DHCPv4, I get the address back.  Why the same couldn't happen 
here?  Why must the tunnel be removed?

> => we have already a problem with IPv4 global addresses: there are not

IANA has been allocating lots of /8's.  Our organization has gotten a 
new /16 as well.  I'd argue that the situation with v4 address 
availability has gotten better.

> => so your concerns are about the DSTM documents?

You could say so, yes.

> => this is a random remark which is not about the WG I-D.

I think it may still be relevant, though.  Lots of people who want 
just simple v4-in-v6 tunnels, or something slightly more sophisticated 
(for example a) and b.1) in above terminology) think they need 
something called "DSTM".  Reading the spec does not give them much 
idea about the goals or the background relevant to their own 
requirements.  The enterprise analysis document seems like a natural 
place to discuss these requirements in the hopes of lessening the 
confusion.

> here I mean the setup of a tunnel between a node and a TEP.

Well, isn't TSP a solution here as well?  Jeroen Massar also had done 
work in this space.  Softwires BOF is working on this.

In any case, as far as I see, the DSTM spec is mostly just describing 
the concept and giving a couple of examples here and there which 
protocols could be used; I don't see how you could write an 
interoperable implementation based on it.

> requirement but I don't think you'd like to use this argument.

In fact, I *do* like to use that argument :-).

In any case, while different kinds of addresses used may or may not 
affect the weighing of tradeoffs, I don't see how b.1) and c) differ 
on the wire.  The protocol to set up the signalling, the tunneling, 
etc. can be the same, i.e., there's no difference on the wire, and a 
decision could be just an implementation decision.

I'm not sure if there's anything requiring interoperability in d) 
either, as I guess you could just remove the tunnel interface if you 
don't have an address anymore -- I'm not sure if it's even worth the 
trouble -- but that's debatable.

> for clear operational advantages for (c)).

I'm only looking for the second, because the first may or may not call 
for this scenario.

> It seems I have now a clear view of the "missing part" in the WG I-D...

yes, and these must be clearly separated from each other, especially 
if there is a scenario calling out for c) or d).

> - the best solution is DSTM...

Frankly, the dominant v6 deployment for this problem seems like 
shooting birds with 160mm cannon (much much trouble that way), but 
that aside..

What are the chances that such a site is not already using NAT, or 
doesn't have the capability of getting more addresses?

In university world, lots of places actually use mostly global v4 
addresses, but on the other hand, they also seem to be quite capable 
of obtaining more from their LIRs and RIR as needed.

I'd be interested in seeing which kind of figures you have, could you 
send e.g., offlist if long?

---

From: Francis Dupont <[email-masked]>
Date: Mon, 22 Aug 2005 19:04:33 +0200

link-layer adaptation),

=> using DHCPv4 over a tunnel is *not* a minor tweak.

   I think it could basically be used itself, and for the service.

=> unfortunately this is not true. BTW the code itself can be reused
but this is not the case of the protocol.

   Could you elaborate why you think it's inappropriate?

=> DHCPv4 can't send a packet over a tunnel which has no addresses,
the limitation comes from DHCPv4 itself and from the nature of tunnels.
But as I've explained this is not dramatic: we already have the code
which provides the service, we only need to add some glue to replace
the protocol, or if you prefer this way a small facility for carrying
DHCPv4 messages and a translator (better if you can only reuse the
binary of the server).

   It is a perfectly fine way to run and use addresses to give each node 
   requiring v4 connectivity a static global address.

=> you only assume that anybody has already enough global addresses.
I'd like that it is true but in fact it is not.

   Those which need 
   
=> RFC 1918 and a NAT? Is it really your idea??

   trade-off.

=> Do you argue there is not realistic scenarios where there is no
choice and the IPv4 address space has to aggressively be conserved?

=> I should have this message somewhere in my mail box.

   consequence AFAICS.

=> it is a direct consequence of the not unlimited lifetime of
the allocation.

   It'd be perfectly fine to deploy only c) with the 
   assumption that if the host needs v4 even once, it gets v4 "for good" 
   (at least as long as isn't rebooted).
   
=> allocations with an unlimited lifetime are not enough aggressive.
(this is why BOOTP was extended to DHCP).

=> in the DSTM context, we already studied what should be the size
of the pool and the lifetimes (initial/renew) from statistics about
some real traffics (it was a good subject for a student training period).

   
=> not c), i.e., I've tried to mean that c) is required and not optional
in this case.

   
=> I don't know how to easily implement tunnels without addresses...
But this is an implementation detail, i.e., you can disable the tunnel
in place of deleting it.

   > here I mean the setup of a tunnel between a node and a TEP.
   
   Well, isn't TSP a solution here as well?

=> DSTM can use TSP (there is a discussion about the choice between
TSP and DHCPv6, both work but we need one and only one :-).

   I don't see how you could write an interoperable implementation
   based on it.

=> I was able to write one so I could?
   
   > BTW you could say that a NAT removes the

   
   
=> IMHO the first one is better even I nearly used DSTM for the second.

   

=> 160mm? Too small! (:-).

=> this is not (yet?) the place where to explain why NATs are bad.
Just say there is a binary only application using embedded addresses
(unfortunately not a silly assumption, don't forget this is about
enterprise scenarios).

=> here I ask my site administrator a /24 or /25, I've still waited
for some years, so don't say this is easy everywhere because it is easy
where you are, PLEASE.

=> the study was paid by a commercial ISP...

Regards

---

From: Pekka Savola <[email-masked]>
Date: Wed, 24 Aug 2005 13:46:49 +0300 (EEST)

> => using DHCPv4 over a tunnel is *not* a minor tweak.

Creating a separate thread out of this.

> I'd like that it is true but in fact it is not.

I think you're assuming that everyone with [not "enough", i.e., 
basically everyone] global v4 address will want c) as a consenquence. 
I disagree with that.

I agree that some might see c) as a potential solution.  A subset of 
those might even think c) is worth the trouble.  But it is IMHO too 
wide a generalization to just say "global v4 addresses -> c)".

> => RFC 1918 and a NAT? Is it really your idea??

Yes.  People use it, and seem to be pretty happy about doing so.

Remember, we're offering *v6* as an end-to-end protocol which doesn't 
have to deal with NAT etc.  In that light providing this functionality 
for v4 might even be counterproductive :)

> choice and the IPv4 address space has to aggressively be conserved?

No, I'm not saying that.  What I'm saying is that people will use 
different (simpler) tools to perform this conservation.  The easiest 
one at their disposal is RFC1918 and NAT.  At some circles, you just 
apply for more address space, depending on the amount of pressure you 
can puton your hostmasters (and the size of assignment window right 
now etc.), you could also get more space to mitigate the need.

My argument is that let people use RFC1918, NAT, or whatever 
mechanisms they want for *v4* address conservation, let us focus on 
*v6* transition, not finding means how to prolong v4 address usage 
under aggressive conservation.

> => it is a direct consequence of the not unlimited lifetime of

No -- getting an address and keeping it until the node is rebooted (or 
some other similar event, e.g., DCHPv4-like lease expires or whatever) 
fulfills that criteria -- the lifetime *is* limited, right?

What you want is to get the addresses back to the pool as early as 
possible, to ensure the most efficient use of address resources.  But 
while that may be your goal, I'm trying to make it clear that there 
may be people just wanting c), not d).

> (this is why BOOTP was extended to DHCP).

But e.g., DHCP-like mechanisms with lease times do have a limited 
lifetime, right?

Maybe d) could be split off to something like:

      d.1) automatic monitoring and tear-down of said v4-over-v6 tunnel(s)
         when an address lifetime expires (and is not renewed)

      d.2) automatic monitoring and tear-down of said v4-over-v6 tunnel(s)
         when the host detects it no longer needs the address/connectivity

(I don't see how the host checks that it no longer needs the address 
in d.2 but that's a separate point -- or how you'd prevent premature 
revokation of the address w/ a lifetime..)

I think you are proposing something that seems to significantly differ 
from what has been deployed today: DHCPv4 is typically used to give 
you an address "for good" (to be refreshed periodically though).  It 
doesn't have provisions (AFAICS) to detect whether the address is in 
use or not when deciding whether to try to refresh the lease or not. 
You're adding a component of potentially fragile nature in the system.

> => I was able to write one so I could?

See above -- there are lots of places where multiple solutions could 
be used; if you pick A, you won't interoperate with other 
implementations which have chosen B.

> (unfortunately not a silly assumption, don't forget this is about

Such applications likely work fine through a TCP proxy or NAT?

> for some years, so don't say this is easy everywhere because it is easy

Maybe you should escalate the issue to your site administrator's boss 
through your boss.  Quite often, the need is not considered 
significant enough, folks figure out different solutions, or you get 
more addresses.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 25 Aug 2005 11:10:13 +0200

=> this is a philosophical issue... Here is not the right place
to discuss it.

=> and say that RFC 1918 and a NAT will solve any problem is productive :) ?

   No, I'm not saying that.  What I'm saying is that people will use 
   different (simpler) tools to perform this conservation.  The easiest 
   one at their disposal is RFC1918 and NAT.

=> NAT is not a general solution: it doesn't work with embedded addresses.
So you have no real counter-argument.

=> the purpose of the v6ops document is to help to solve problems,
not to enforce something. So as the previous scenario is credible
DTSM (i.e. c)) has to be referenced.

   
=> d.1) is the thing I think about.

=> d.2) should be loosely done by a good choice of parameters (initial
and renew lifetimes), i.e., it should not be necessary to be so
aggressive.

   in d.2

=> I know: this is a standard garbage collection problem (see below).

   but that's a separate point -- or how you'd prevent premature 
   revokation of the address w/ a lifetime..)

=> I can't see what is the "premature revokation" here: if an address
is still in use and is near to expire, just renew?

=> in fact it is very easy to do because the problem is not about
the address use but the global IPv4 use. In my implementation I
simply use the reference count of the default route because the
neighbor cache is implemented as cloned children of it.

=> anything is potentially fragile. Do you really believe that a NAT
is not fragile?

   
=> they don't work through a NAT so an ALG is needed per application...
Can I add "encrypted" or "ciphered" before embedded?

Regards

---

From: Pekka Savola <[email-masked]>
Date: Mon, 29 Aug 2005 10:34:39 +0300 (EEST)

> => and say that RFC 1918 and a NAT will solve any problem is productive :) ?

Yes -- at least it will encourage people to see the benefits of v6 in 
a different light :)

> So you have no real counter-argument.

Yes, it doesn't work, but what I'm asking here is a reality check.

I guess what you're saying is that some sites have binary-only, 10+ 
old applications which have embedded addresses.  Those applications 
work just fine if you use them internally in the site only (using 
RFC1918 addresses).

Do you want to provide such an application to the outside?  -- REALLY? 
Even if you do, I don't think a site has dozens of such applications 
on dozens of hosts.  Those applications are required to work reliably 
(otherwise they would not still be provided, at great pains).  Thus I 
don't see why the addresses would need to be set up and torn down 
dynamically -- manual config would probably be more reliable and more 
useful.

Or do you want to use such an application (provided by someone else) 
from the outside?  Again, I'm not sure if I'd buy the argument that 
these are commonplace enough to be worth the trouble -- remember that 
NATs are already so widely deployed, that these applications cannot be 
used from the majority of the networks.

> DTSM (i.e. c)) has to be referenced.

I don't think the purpose of any v6ops document is solve problems in 
one's *v4* network by *v4* mechanisms, so it's not entirely clear if 
the mechanism is in the scope of this WG.

> is still in use and is near to expire, just renew?

If an application is still in use (but the host may have very much 
difficulty in figuring out whether it's used or not!), the address 
lease should not expire, otherwise you've prematurely taken off an 
address and the application ceases to work.

> neighbor cache is implemented as cloned children of it.

I'm not sure I understand the implementation well enough to say 
whether that would work or not (I guess it will work as long as the 
application regularly sends packets and "uses" the default route), but 
how would that work for a server application which just binds to an 
address and doesn't send out anything?  Or a client application which 
just happens to sit quietly for some time?

> => anything is potentially fragile. Do you really believe that a NAT

Sure, NAT can be fragile as well.  The users and administrators 
typically understand the main fragilities of NATs though.  This is of 
a different kind.  The mechanisms used by DSTM are typically 
implementation-dependent (such as the way you use the default route 
refcount).  So, every implementor has to figure out his/her own 
mechanisms on your own, and each approach is likely to have some 
issues; the specification cannot help here as there we're too deep in 
the realm of implementation-specificity.

As I said earlier, this approach may or may not be something that a 
vendor could implement, but there don't seem to be bits in the wire 
that need standardizing, and the generic concept is probably NOT 
something we want to specify due to its fragilities, 
implementation-specificity, etc.

> Can I add "encrypted" or "ciphered" before embedded?

Are we talking about the same (very old, binary-only) applications? 
The strongest encryption in these I've seen has been "XOR" (for just a 
part of the payload), and even that was a surprise :)

---

From: Francis Dupont <[email-masked]>
Date: Mon, 29 Aug 2005 12:00:11 +0200

=> sorry but I am tired to discuss about this topics. You don't want
to consider cases where NATs cannot be used or where people don't want
to use NATs, and this point is obviously NOT in the scope of the WG.

   I don't think the purpose of any v6ops document is solve problems in 
   one's *v4* network by *v4* mechanisms,

=> DSTM is not a *v4* mechanism.

   so it's not entirely clear if the mechanism is in the scope of this WG.
   
=> DSTM and relevant scenarios are, this discussion is not.

   I'm not sure I understand the implementation well enough to say 
   whether that would work or not

=> it works even the implementation way I discribed works only for
some kernels (for other kernels the PCB table has to be scanned
for instance because routes are not referenced by PCBs).
Do you claim that DSTM is not implementable?
   
Regards

PS: this is my final message about the topics.

---

From: Tim Chown <[email-masked]>
Date: Mon, 29 Aug 2005 11:02:58 +0100

> the mechanism is in the scope of this WG.

If you deplay a v6-only network infrastructure then v4 transport is a 'v6
problem'.   I guess he crux of your argument is
a) why not run dual stack, even with v4+NAT
b) why can't apps be updated to use IPv6

Tim

---

From: Pekka Savola <[email-masked]>
Date: Mon, 29 Aug 2005 13:37:18 +0300 (EEST)

> b) why can't apps be updated to use IPv6

Depends on what you mean by 'dual stack'.  For this particular thread, 
I think my main arguments are:

  - if you want to run v6-only network but dual-stack hosts, that's 
fine, you can run stuff in v4-in-v6 tunnels -- for example, scenario 
a) or b.1) from the list below.  HOWEVER, I don't see why you [in 
practical scenarios] need mechanisms to give (very) temporary global 
v4 addresses on the nodes, and then take them away (e.g., c) or d) 
from the list below).  You can just deploy private v4 addresses if you 
have address shortage, or use more stable v4 global addresses.

  - the mechanisms which go beyond DHCPv4-like functions for address 
assignment on v4-in-v6 tunnels do not have any bits-on-the-wire 
interoperability requirements, and thus do not require 
standardization.  Such mechanisms can also be brittle and very 
implementation-specific, and I'd be hesitant to even try to encourage 
them.

  - the DSTM spec is not clear enough on its scope and intent and 
should not be referred to in a WG document.  My own take here is (if I 
understand the intent of the spec) that we don't (anymore) require a 
document like that, but rather should concentrate (in some other WG 
like softwires, it's out of charter here) on creating the actual 
protocol specification(s).

.........................

  b.1) the set-up of the bidirectional v4-in-v6 tunnel with the tunnel
     server(s) which can happen without user intervention, e.g., using
     a process described in draft-palet-v6ops-tun-auto-disc-03.txt.
     This must include a way to auto-configure a v4 address [e.g.,
     DHCPv4-like method].

[ everything below here doesn't have any direct bits-on-the-wire 
interop requirement (maybe except e), it can be just a local vendor's 
optimization ]

---

From: Tim Chown <[email-masked]>
Date: Tue, 30 Aug 2005 10:24:55 +0100

On Mon, Aug 29, 2005 at 01:37:18PM +0300, Pekka Savola wrote:
> Depends on what you mean by 'dual stack'.  

Sorry, I meant 'on the wire'.  To agree that something 'DSTM-like' is
going to be necessary, we have to assume and agree that IPv6-only
infrastructures will be deployed where some nodes have to use IPv4
communications.   I think we agree on that.

> For this particular thread, I think my main arguments are:
> 
> a) or b.1) from the list below.  

So far so good :)

> HOWEVER, I don't see why you [in 

Well, there is a tradeoff.  You could run IPv4+NAT on all the nodes that
need IPv4.   If you have enough IPv4 global addresses you could run stable
permanent addresses on all those nodes.  Either of these could/should use
tunnel setup and address allocation mechanisms that could also be used
by something 'DSTM-like'.   

But if you have limited IPv4 global addresses, and would like to avoid NAT, 
then some form of dynamic, short-term addressing is desirable.  I guess the
question then is how realistic a scenario is that?
 
> implementation-specific, and I'd be hesitant to even try to encourage 

Agreed, whether the protocol is used for short-term or long-term addressing,
the mechanism can be the same.   Something 'DSTM-like' *could* be used for
scenarios with long-term stable addresses in use.   In principle there could
be a mix of long-term stable global addresses (servers) and IPv4+NAT (clients)
on the network.
 
If the site's only IPv4 communication requirements over IPv6 infrastructure
are internal, then private IPv4 addresses should be just fine.

> protocol specification(s).

Which is exactly what was suggested - take the 'DSTM-like' requirements and
potential solutions into the softwires WG.

But I would still maintain that the ent-analysis must include the 'IPv6
dominant' scenario, talk about the issues we've discussed on this list, and
can cite DSTM as an example (the only example to date?) of a solution
approach.   The text can also say that further work on nailing down the
'DSTM-like' protocol details is required, and could even recommend that that
happens in softwires.   That's pretty similar to how Teredo was supported
in the unman analysis I recall.

What actually emerges from softwires, well, we'll just have to wait and see;
so far there hasn't been any charter discussion.

-- 
Tim/::1

---

From: Pekka Savola <[email-masked]>
Date: Wed, 31 Aug 2005 09:22:31 +0300 (EEST)

> question then is how realistic a scenario is that?

Yes that's the question, and in addition, "is this something v6ops WG 
should be concerned about?"  I don't think that's given -- our 
business is (IMHO) not extending the life of (public) IPv4 addresses, 
becuase there are alternatives (get more addresses; use private 
addresses; use proxies)

If someone wants to create a clear specification how you do that, get 
a WG started or whatever, that's OK, but let's not discuss or 
recommend it here.

> dominant' scenario, talk about the issues we've discussed on this list,

I've no objection with this.

> and
> approach.

I do object to this though, as I think DSTM will do more to confuse 
the readers than help -- becuase it seems to be trying to describe 
both a number of concepts and a bunch or protocols that could be used 
to fulfill the concepts (and the protocols are not interoperable).

Note that TSP for example (which can be one implementation of DSTM 
"concept") already includes most if not functionality -- certainly 
(AFAICS) everything that's needed for interoperability.

> The text can also say that further work on nailing down the

Lot's of stuff should happen on softwires (or somewhere else but not 
here, as we're explicitly chartered NOT to do protocols).  But IMHO, 
we just can't reference a half-baked spec at this point.

It's fine (and recommended!) to discuss these requirements in the 
enterprise analysis, e.g., based on the list of a) - d) goals I 
included in the previous message.  But pointing at specs should be 
done with great care because many of those specs may not be clear 
enough on what their scope is (for example, I think TSP spec is clear 
enough -- it's clearly defines a protocol specification with a 
definite scope).