[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WGLC ent-analysis-03: DSTM

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

On Wed, 17 Aug 2005, Francis Dupont wrote: 
  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.

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

   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.

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

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

=> this (b-a) is DTI

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.

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

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

  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.

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?

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

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.

  My point is that I'm having hard time figuring out:
    1) what the document means when it's recommending DSTM, and

=> the references

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.

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