[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WGLC ent-analysis-03: DSTM
In your previous mail you wrote:
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.
=> 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 :-).
This must include a way to auto-configure a v4 address [e.g., DHCPv4].
=> I believe you mean something providing the same service than DHCPv4,
not DHCPv4 itself.
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]
=> I believe you have "direct tunnels" in the b.2 idea?
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]
=> 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.
d) automatic monitoring and tear-down of said v4-over-v6 tunnel(s)
when the host detects it no longer needs the address/connectivity
=> as I've already explained, d) is a consequence of c).
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).
=> I agree: traffic optimization is not the problem to solve.
- 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
=> c) is *not* an option when you have not one address per node, i.e.,
when b.1) is not usable.
- 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.
=> perhaps I have misunderstood d) but when the IPv4 address expires the
tunnel must be torn down...
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....
=> we have already a problem with IPv4 global addresses: there are not
enough!
> => 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.
=> so your concerns are about the DSTM documents?
> => 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,
=> 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.
> 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).
=> I refer to the b-1 tunnel mechanism only (not the way to setup them).
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).
=> 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.
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?
=> 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.
> 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,
=> 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.
> 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.
=> 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
Francis.Dupont@enst-bretagne.fr
PS (for authors): BTW the right spelling of IPsec is IPsec (cf RFC2401bis).