Re: Please review section 3 of Enterprise analysis

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 26 Jan 2005, Pekka Savola wrote:
> (co-chair hat on)
>
> There haven't been comments since the revision of Enterprise Analysis doc was 
> published, so asking explicitly.
>
> Please review section 3 of the Enterprise analysis, and send your comments on 
> the list.  Please try to do this within about a week, by 2nd February.
> (hat off)

I took a look mainly at the revised section 3.  Below are my 
*personal* comments, to get the commenting started.

I've mainly three kind of concerns/suggestions for improvement:
 1) terminology clarifications, so that we're talking about the same
    thing
 2) the model how the enterprise should go about deciding which cases
    to support, implying how we should present the cases
 3) input on the matrix and classification of different cases

.....

First, I'd like to note a few terminology/scope issues.

 - What is the more precise definition of 'host X network'?  Does that 
mean the IP capabilities supported by routers on the link(s) where the 
host plugs into, IP capabilities of the particular (geopgraphical) 
site ("whole network") or what? This has *major* impact on how to read 
the table, and how to think about the scenarios in general.  I've 
assumed the latter.

 - The first paragraphs restricts this disucussion only to dealing with
communications between different parts of the same enterprise, e.g.,
different branch offices at different countries etc.  I think this
restriction may be useful (though it's difficult to say), but this is the
first time I've seen it.

However, it is worth observing that I'd suspect a major goal for an
enterprise would be to also publish some services to the outside, or use
outside services.  According to this scope, these would be out of scope?

.....

The document states that it focuses on L3 issues.  That's OK as such, as
long as it's clear where those L3 decisions come from.  That is, AFAICS,
typically the v6 deployers should ask two main questions:

 1) "which kinds of applications [v4-only, ds, v6-only] do we want to
provide [to whom -- v4-only, ds, v6-only?] or use ourselves?"

 2) "are there any constraints on which network topologies should or should
not be supported?"

Based on that, you could take 1) as a basis, strike out or underline those
cases reflected by 2), and then go through and consider the rest of the
cases and every time ask the question, "is this something we want to
support; are there workarounds to avoid this scenario?"

The classification I presented below is an attempt to make that decision
easier from the _application_ perspective..

.....

I still have issues figuring out how to understand the matrix.  For
example, 5 first cases are "IPv6/DualIP" app/host scenarios, with IPv4 or
dual IP in the middle.  But my arithmetrics says there must be 2^3 = 8
different cases -- what's missing? dual-dual-dual
(network-provider-network), which is trivial; v4-v4-v4 which is
non-trivial; dual-v4-v4 (v4-v4-dual is there though) which is also
non-trivial.

This makes me think that there must be some clearer methodology for dealing
with these cases.

What I could think of was breaking up the section to different, higher-level
cases, in free-flowing text, which could then refer back to a part of a
matrix if needed.

I also observe that there should be two cases which are likely relatively
similar, whether you look at this from the "server" or "client" perspective
(as above: dual-v4-v4 and v4-v4-dual may not be 100% the same, but it might
make sense to try to group these together and see where that goes)

What I came up with were (with some thoughts on potential solutions in
[[]]'s:

 1) "IPv4-only legacy application communicating with newer IPv6-only app"
    (this is currently excluded from analysis, on purpose..)

   a) the v4-only app's host or network is dual-IP
       [[ * translation at the host or "close" network? ]]

   b) the v4-only app's network is v4-only
       [[ * avoid this case if possible!
          * the only choice would be translation at SP or "remote" network]]

 2) "IPv4-only application is used through a non-IPv4 network"

   a) host providing the application is dual-IP
      - host's network is v6-only
      - peer's network is v6-only
      [[ * in both cases, tunnel to SP,  peer nw, or peer host? ]]

   b) host providing the application is v4-only
      - host's network is v6-only
        [[ * avoid this case if possible!
           * otherwise, would have to do double translation at SP or peer network..]]
      - host's network is dual-IP
        [[ * straightforward tunneling, similar to 2.a) ]]

 3) "Dual-stack applications on dual-stack hosts"

    a) It just works (TM) when networks are any kind of mix of dual-IP and v4-only.
       However are two pathological cases..

    b) "local network v6-only, SP v4-only, peer network v6-only"
        [[ * straightforward tunneling. ]]

    c) "local network v6-only, SP v4-only or dual-IP, peer network v4-only"
        [[ * similar to 2.a) ]]

  4) "IPv6-only application on Dual-IP hosts through v4/dual-IP networks"

    a) networks support dual-IP, but the SP is v4-only
        [[ * straightforward tunneling between the networks ]]

    b) networks are v4-only, the SP is v4-only or dual-IP
        [[ * tunneling between the hosts, or via the SP in the middle ]]

    c) one network dual-IP, the other v4-only; the SP is either v4 or dual-IP
        [[ * another case of host-to-network tunneling, like 2.a) ]]

    d) both networks and the SP are dual-IP
        [[ * trivial native v6 case ]]

  5) "IPv6-only application on Dual-IP hosts through v6-only networks"

    a) "just works" if both networks are v6-only, SP is dual-IP
        Otherwise..

    b) the same as 3.b)

    c) the same as 3.c)

This is a slightly different way of presenting a (longer, more exhaustive)
matrix -- I'm sure there are probably better ways, but at least to me, this
is MUCH easier than looking at the matrix and trying to figure out the
differences between different options and what they mean in practice..

This doesn't mean the matrix couldn't be there, but that maybe it could be
something different cases from a classification like above could refer to
somehow.

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