[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WGLC ent-analysis-03: DSTM
On Mon, Aug 29, 2005 at 01:37:18PM +0300, Pekka Savola wrote:
> On Mon, 29 Aug 2005, Tim Chown wrote:
> >On Mon, Aug 29, 2005 at 10:34:39AM +0300, Pekka Savola wrote:
> >>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.
> >
> >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
>
> 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:
>
> - 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.
So far so good :)
> 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.
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?
> - 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.
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.
> - 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).
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
> .........................
>
> 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
> 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].
>
> 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]
>
> [ 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 ]
>
> 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.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
>
> 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).
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings