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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Oct 2004 23:00:23 +0200

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

---

From: Tim Chown <[email-masked]>
Date: Mon, 25 Oct 2004 02:29:28 +0100

> upgrade to the new API. Why make it harder than it needs to

I think because there is no one-size solution.  I suspect that Scenario O
may be the most common though, but by how much, it's hard to tell.
 
> they refer essentially to what I have shown above as

That is baed on our experience (in 6NET), but as Jim says others contributing 
to the analysis are doing things a different way and that experience is
being reflected.
 
> this draft to make such a statement about ULAs.

Mea culpa.  Both references should have read as per 4.1, but it could better
say in both places:

  "In this document we do not discuss the deployment of Unique Local 
   IPv6 Unicast Addresses [ULA]."

> The simplest solution is to remove both these references to

I would prefer to mention them, but just leaving it out is OK too.
 
> stack would be the first essential step for many enterprises.

That is what we did, so I would agree with adding such text.  However,
note (again as Jim said) this is a more Layer-3 oriented view, so beyond
basic services like DNS we shouldn't get lost in application space too
much.   (ISP, 3GPP and unmanaged alos stayed in Layer 3 I believe).
Otherwise it'll be a big document :)
 
> setting up RFC 3056 correctly than a large enterprise.

Well, 6to4 and the tunnel broker *are* being used for both network and
single node access to remote sites.   If you want the text changed so
that 6to4 is only for networks, and the broker is for hosts or networks,
that's fine.   Just reporting actual usage...

6to4 is bad for a number of reasons, reliance on the relay being one.
Why use 6to4 or a broker for a large enterprise when a specific tunnel
can be set up?

> internal network usage at all, apart from updating the prefix.

Well, "apart from updating the prefix" menas a whole site renumbering
exercise, and that's uncessary pain when you can use 2001: space from an
ISP who is quite likely to be your future native IPv6 provider.
 
> only a recommendation to the RIRs.

Fair point;  could cite both?
 
> to deprecate NAT-PT, it probably should not be mentioned.

There seem to be a few people who think NAT-PT should live on (though I'm
not one of them, I felt the solution should be mentioned, but I personally
wouldn't put it in the recommendations section of the analysis - and that
WILL be a hot potato in this draft!).
 
> secure IPv4 "call home" today.

Yes, I agree we should add some IPv6 over IPv4-VPN text here.
 
Thanks for the comments Brian.

-- 
Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Oct 2004 14:03:57 +0200

Thanks Tim, just one follow-up

> Why use 6to4 or a broker for a large enterprise when a specific tunnel

Indeed, that is better if possible. But with a disobliging ISP, it
might not be possible.

> ISP who is quite likely to be your future native IPv6 provider.

Again, that doesn't work with a disobliging ISP. And we just *have* to
make prefix updates a feasible option for IPv6; otherwise we will slowly
slide back to a pre-CIDR state as sites wave money at ISPs.

     Brian

---

From: Pekka Savola <[email-masked]>
Date: Mon, 25 Oct 2004 17:03:18 +0300 (EEST)

> Indeed, that is better if possible. But with a disobliging ISP, it

I'm not sure if I understand your comment.  Even if your own ISP would
not be willing to set up a configured v6-in-v4 tunnel, there could be
some other ISPs (for example, the ones for whom the enterprise pays
for this :), which is willing to set up a configured v6-in-v4 tunnel.

Yes, this takes some effort from the enterprise, but if enterprise is
doing anything with IPv6 except testing it out, that seems like the
only manageable alternative, with some guarantee of actually working
reliably.

So, IMHO, enterprises can certainly test IPv6 using 6to4, but I don't
think it would be a good idea to recommend it for much more than that.

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

---

From: Tim Chown <[email-masked]>
Date: Mon, 25 Oct 2004 15:53:09 +0100

> Indeed, that is better if possible. But with a disobliging ISP, it

Well, I admit in the academic networking world we have it easy(er) in
that our NRENs offer v4 and v6, so we just get a tunnel if needed (as
it happens we're native, if 6PE counts as native).

However, I don't see it as a big problem for a site to get a tunnel
set up.   A very successful IPv6 deployment in Europe was in Germany
on the 6WiN where they had 300+ commercial and academic tunnels to
end sites, thanks to the JOIN project.  
 
> slide back to a pre-CIDR state as sites wave money at ISPs.

I agree, hence draft-chown-v6ops-renumber-thinkabout-00 to complement Fred's
work... but I would rather recommend tools that reduce the likelihood of
renumbering in the first place.

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 25 Oct 2004 15:53:57 +0100

> think it would be a good idea to recommend it for much more than that.

Yes, and then the "test" is little more than a SOHO-like testbed, where
6to4 may be commonly used anyway...

-- 
Tim

---

From: Salman Asadullah <[email-masked]>
Date: Mon, 25 Oct 2004 11:51:53 -0700

>think it would be a good idea to recommend it for much more than that.

Right.  This was one of the main idea of using 6to4 while testing it among 
several enterprise campuses and using a 2002 followed by global IPv4 
address (forming a fake global IPv6 address).  So, if the the enterprise 
did not get a a chance to get a real IPv6 address, they can just use 6to4 
tunneling address and test things out among several sites and also connect 
to IPv6 Internet by using a 6to4 Relay.

But, if the enterprise planning to move to the next step, then they should 
plan of getting a real global IPv6 address (2001:).

Regards,
Salman

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Oct 2004 10:20:42 +0200

> 6to4 may be commonly used anyway...

We don't have to agree on this. If an enterprise can find a configured
tunnel provider, fine. If they can't, they may choose a tunnel broker
or a 6to4 relay. It isn't the IETF's job to tell them.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Tue, 26 Oct 2004 11:54:14 +0100

> or a 6to4 relay. It isn't the IETF's job to tell them.

As it's an analysis document making recommendations, just as per the other
three analysis docs we should do that... e.g. just as we made Teredo a
last resort mechanism for unmanaged, we might agree to place 6to4 as last
resort for an enterprise.

My ordering would be (topology being alike):

1. native

2. manually configured tunnel

3. tunnel broker

4. 6to4

i.e. put native, managed connectivity ahead of automatic, esp. where the
automatic has less predictable behaviour.   Other factors also come to
bear, like using 2002::/16 and heaving to renumber...

-- 
Tim