Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt

[Brian E Carpenter <brc@zurich.ibm.com>]

I have a number of concerns about this document, and some smaller items.

1) My first concern is that somehow it misses the most important
case and the way I would recommend any enterprise to go.

In the terminology of the document that case is


 ======================================================
   |Application |Host 1 |Service |Host 2 |Application |
   |----------- |Network|Provider|Network|----------  |
   | Host 1 OS  |       |        |       | Host 2 OS  |
 =====================================+================
   |Dual or IPv4|       |        |Dual IP|Dual    IPv4|
 0 |    ----    |Dual IP|Dual IP |  or   |---- or ----|
   |    Dual    |       |        |v4 only|Dual    IPv4|
 ======================================================

In other words, why would an enterprise choose to paint itself
into any of the awkward corners of the other 13 scenarios?
Just go for a dual stack operating system and routing system,
and keep calling your software suppliers until they
upgrade to the new API. Why make it harder than it needs to
be?

In fact, sections 4 and 7 are written in this spirit -
they refer essentially to what I have shown above as
secnario 0.

I just don't get what are the drivers for the other
13 scenarios. Why would an enterprise accept any of them,
rather than beating on its suppliers for dual stack
solutions?

2) My second main concern is these two statements:

> 4.1  Phased Dual-Stack Deployment
...
>  In this document we do not advocate or discuss the deployment of
>  Unique Local IPv6 Unicast Addresses [ULA].

> 7.3.2 Obtaining global IPv6 address space
...
>  Unique Local Addressing [ULAs] should not be used for enterprise
>  networks.

Not true and not OK. They were to a considerable extent designed for
enterprise networks. There will be a draft soon that discusses
how they could be used in enterprise networks, precisely to
respond to some of the reasons people use NATs. It isn't OK for
this draft to make such a statement about ULAs.

The simplest solution is to remove both these references to
ULAs.

3) My third main concern is that the draft doesn't discuss
the deployment of DMZs, which are a feature of all major
enterprise networks.  A related point is that it doesn't
discuss how an enterprise will offer an IPv6 "web presence"
(or email presence) regardless of the state of its internal
transition. Maybe converting all its DMZ servers to dual
stack would be the first essential step for many enterprises.

Details:

The summary at the end of section 1 doesn't mention section 7.

> 4.6  Other considerations
>
> There are some identified issues with turning IPv6 on by default,
> including application connection delays, poor connectivity, and
> network insecurity, as discussed in [V6DEF]. The issues can be
> worked around or mitigated by following the advice in [V6DEF].
>
> <more to go here>

At least DNS, network management, and security policies need to be
covered.

> 5.1  Internal versus External Tunnel-End-Point
>
>
>  The upstream provider could have already deployed some IPv6
>  service, either native IPv6 in its backbone or in the access
>  network, or a combination of both. Also, or alternatively, could
>  have deployed one or several transition mechanisms based upon
>  tunnels, for example in the case where the access network doesn't
>  support IPv6. In this case, the enterprise could decide to use
>  those available transition services from the ISP. However, this
>  will usually mean that the each of the different nodes in the
>  network will have their own IPv6-in-IPv4 tunnel. Then, the IPv6
>  intranet communication will not be efficient, as it will require
>  all the traffic to be forwarded by the IPv4 infrastructure to the
>  Tunnel-End-Point located at the ISP.

This would be unacceptable to 99% of enterprise security
managers.

> 7.3.1 Obtaining external connectivity
>
>
>  The enterprise service provider would typically be a
>  topographically close (to minimize connectivity RTT) IPv6 provider
>  that is able to provide an IPv6 upstream link.
>
>  It would be expected that the enterprise would use either native
>  IPv6 upstream connectivity or, in its absence, a manually
>  configured tunnel [BCNF] to the upstream provider.
>
>  It is not recommended to use 6to4 [6TO4] or a tunnel broker [TBRK]
>  for an enterprise deployment.  The enterprise has a requirement for
>  long-term, stable IPv6 connectivity.  6to4 and the tunnel broker
>  are more appropriate for SOHO or single node environments.

Sorry, but that's wrong. First of all, single-node 6to4 isn't
an IETF solution - it has never been documented - so it's not accurate
to cite the RFC. Secondly, 6to4 as described in RFC 3056 will work
just fine for an enterprise - until the day its own ISP provides
native connectivity, of course. I'd say a SOHO user has less chance of
setting up RFC 3056 correctly than a large enterprise.

>  ...Use of
>  6to4 also prevents the enterprise adopting aggregatable global IPv6
>  addressing from the outset.

True... but so what? It's a solution you use only as long as you have
to, and then you switch to an aggregatable prefix. This wouldn't affect
internal network usage at all, apart from updating the prefix.

> 7.3.2 Obtaining global IPv6 address space
>
>
>  The enterprise will obtain global IPv6 address space from its
>  selected upstream provider, as provider assigned (PA) address
>  space.
>
>  The enterprise should receive at least a /48 allocation from its
>  provider, as described in [ALLOC].

I think you should refer to RIR policy directly; that RFC is
only a recommendation to the RIRs.

> 7.4.6  IPv4-IPv6 interworking
>
>
>  In the case of an IPv6 only node in an IPv6-dominant or dual-stack
>  enterprise, wishing to communicate with external IPv4-only systems,
>  some interworking (translation) method is required.  The
>  translation could be applied at Layer 3 (e.g. [NAT-PT]), Layer 4
>  (e.g. [SOCKS]) or Layer 7 (a dual-stack application layer gateway -
>  ALG).

I would also refer to a Layer 7 proxy. Also, since we seem to be about
to deprecate NAT-PT, it probably should not be mentioned.

> 7.5.2  Supporting remote access
>
>  Where an enterprise's users may be working off-site, and their
>  transient ISP has no IPv6 support (natively or through transition
>  aids) the enterprise should consider deploying its own transition
>  (remote access) aid.
>
>  Such an aid may be either a tunnel broker [TBRK], ideally one that
>  supports operation through an IPv4 NAT, or a 6to4 relay [6TO4].  If
>  a 6to4 relay is offered, the site should be aware of security
>  issues with operating 6to4 relays [cite ref?].

I think it's much more likely to be an IPSEC or IP-over-TLS tunnel,
which could be v6-in-v4 or v6-in-v6. That's how many enterprises offer
secure IPv4 "call home" today.

> 8  Applicable Transition Mechanisms
...
>  Basic Configured Tunnels:
>
>  6to4:
>
>  Tunnel Broker:
>
>  Teredo:
>
>  DSTM:
>
>  ISATAP:
>
>  NAT-PT:

Well, again, if we are deprecating NAT-PT, we can't include it here.
And the ALG/proxy alternative to NAT-PT needs to be listed. Probably,
IPv4-in-IPv6 tunnels should be listed too.

>
>  ======================================================================
>    |Application |Host 1 |Service |Host 2 |Application |   Recommended
>    |----------- |Network|Provider|Network|----------  |   Transition
>    | Host 1 OS  |       |        |       | Host 2 OS  |   Mechanism
>  =====================================+================================


You need to give some rationale for the recommendations in the last column.
But in any case, my main concern 1) applies to this whole table. Scenario 0
is the interesting one, and it's missing.

The issue with NAT-PT applies to the entries for "translation", all
of which I would replace by "ALG/proxy."

> Appendix B - Crisis Management Network Scenarios

What's the value-add of this material in this document? It seems that
it should be published separately.

   Brian