Subject: Enterprise scenario text proposal

From: "Dave Thaler" <[email-masked]>
Date: Thu, 18 Mar 2004 16:34:08 -0800

From the minutes:
> Dave Thaler: As the slide says, enterprise scenarios document doesn't
yet
> give much help in what's required.  But Enterprises want v6 with
little
> overhead in any case.
> Jonne: not discussing enterprise today, Dave should contribute to
> Enterprise work.

To start following up on my action item, here's text I'll propose for
possible addition to the draft-savola-v6ops-tunneling-00.txt draft.
For now, I only consider "Scenario 1" (as defined in 
draft-ietf-v6ops-ent-scenarios-01.txt), which is making IPv6 equivalent
to IPv4.  Personally I don't consider scenario 2 (supporting only a
particular set of apps) as significantly unique to the enterprise
scenarios and as it's not in any of the other non-enterprise scenarios,
I will ignore it.  I leave scenario 3 (essentially IPv4 over native 
IPv6) to others, as I don't have data on that scenario and it's not
clear to me whether it's really enterprise specific (could this arise
in 3GPP? I don't know).

+'s indicate proposed additions to the existing draft.

---
3.3 Enterprise Scenarios

   The only scenario which is obvious at the moment is when the
   enterprise wishes to deploy IPv6 without changing the gear to be
   dual-stack, without injecting IPv6 into existing VLANs, or without
   adding additional IPv6 routers in the VLANs.

+  There are three subcases of this scenario:
+
+  1. When the enterprise does not NAT between different parts
+     of the internal network.  This case is useful to separate
+     from case 2 merely because it is generally the common case,
+     where simplicity is the most highly valued.
+
+  2. When NATs exist within the enterprise network, e.g., to connect
+     branch offices to the corporate network.
+
+  3. When the enterprise internally uses multicast
applications/protocols
+     that they want to transition to IPv6.  Here the enterprise has 
+     already deployed intra-domain IPv4 multicast to support this
usage.
+     As with case 1, there are no internal NATs in this case since IPv4

+     multicast itself does not cross NATs.
+ 
+  NAT traversal must be supported in case 2, and IPv6 multicast must
+  be supported in case 3.
+ 
+  The need for direct connectivity in all cases is strong due to two 
+  factors: 
+   * the high end-to-end bandwidth requirements for enterprise 
+     applications, e.g., many clients accessing various servers, 
+     such that bottlenecks occur if all traffic must be funneled 
+     through one or a few tunnel endpoints;
+   * the use of collaborative applications, possibly including 
+     high-bandwidth streams such as audio/video.
+
+  Finally, most enterprise networks currently lack IPv6 expertise, and
+  have a great need to keep costs low.  Hence simplicity and low 
+  infrastructure costs are also required.

---

4.1 Scenarios Evaluation

                                                          +++++++++
                  NAT-T Direct ISP Secure Simple   Low    Multicast
                                                 Overhead
     Unman 1.1     *       *     N    -      -       -      -
     Unman 1.2     *       N     *   -/*     -       -      -
     Unman 2       *       -     *    -      *       -      -
     3GPP 1        N      -/*    *    -      *       *      -
     3GPP 2        N      -/*    *    -      *       *      -
+    Enterprise 1  N      -/*    *    *      *       -      -
+    Enterprise 2  *      -/*    *    -      *       -      -
+    Enterprise 3  N      -/*    *    -      *       -      *

   Legend: *  = MUST; -  = Nice to have; N  = No

+  Multicast support indicates whether the mechanism must be able
+  to support multicast traffic.

---
4.2 Mechanisms Evaluation

   One should note that we are not evaluating the specific version of
   the specification, but rather the mechanism in a more generic sense
   ("which features could this mechanism easily be made to work with?").

                                                                   +++++
            NAT-T  Direct  ISP  Secure Simple   Low   Impl.  Depl. Mcast
                                             Overhead
     Teredo  Y       Y      N      Y      N      N     R      Y     N
     ISATAP  N       Y@     Y     N/R     R      Y     Y      R?    N
     TSP     Y       N      Y?     Y      R      N     R      R?    Y?
     STEP    Y       N      Y      Y     Y/R     Y     N      N     Y?
+    L2TP    Y       N      Y      Y      N      N     Y      Y     Y
+    6to4    N       Y      N      N      Y      Y     Y      Y     N
+    6over4  N       Y      Y      R      Y      Y     Y      R     Y

     @: intra-site, no NATs in the path

   Legend: Y  = Yes; R  = Relatively good; N  = No

+  Multicast indicates whether the mechanism is able to support 
+  multicast traffic.

---

-Dave

---

From: Tim Chown <[email-masked]>
Date: Fri, 19 Mar 2004 09:42:01 +0000

Hi,

We are deploying IPv6 in an enterprise here (1,500 users, ~1,000 hosts)
and are documenting the process within the 6NET project.  I can certainly
write up this experience and issues (there is a "similar" draft for an
ISP deploying customer dialup/DSL provision in Japan).   Pekka is OK with
the idea, and we can probably produce this within the next 4 weeks as a 
first draft.   A specific example may help discussion.

Regarding 3.3, we *have* deployed by injecting prefixes into VLANs, and
I know other etnerprises that are doing the same.   We also have full
SSM and ASM multicast v6 running enterprise-wide, and have for example
used Flute/Mad for reliable IPv6 multicast file sharing around a number of
European academic enterprise sites.

The gaps are largely with commercial apps, like MS Exchange, but I'll cite
them all in the draft.

Tim

---

From: "Jeroen Massar" <[email-masked]>
Date: Fri, 19 Mar 2004 11:30:23 +0100

Dave Thaler wrote:

<SNIP>

> +    6over4  N       Y      Y      R      Y      Y     Y      R     Y

In cases of TSP and STEP I don't think these should be listed here, as
these two are configuration methods, while Teredo/isatap/l2tp/6to4/6over4
are protocols that go over the link after being configured by such a method.

TSP can do 6over4, but also 6inudp4 or whatever it is called and it can
be used to configure a machine to setup a l2tp connection and some
others, depending on the availability of a protocol.
When TSP uses 6over4 as a protocol it thus doesn't support NAT-T.

Also 6over4 is spoofable when one is able to spoof IPv4 packets.
Eg mentioned by the following, but I guess that is why it is 'R' ;) 
http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-tunnel-disco.pdf
Simplicity of 6over4 depends on the configuration method and or
knowledge of the person setting it up or is it meant as
'simplicity of the protocol' ?

There are also at least two seperate Teredo implementations but
I guess you are more aware of those ;)

TSP and STEP thus can do Multicast depending on the protocol it uses.

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Mar 2004 13:34:29 +0200 (EET)

Thanks for your input.  A few comments inline..

> +     where simplicity is the most highly valued.

Fine with me.  Also, adding a notion that private addresses (even if
no internal NAT) are often used.

> +     branch offices to the corporate network.

I'm not sure of how applicable this is, but fine with me.

> +     multicast itself does not cross NATs.

There are a few enterprises which are using multicast very extensively
at the moment.  Not many, but a few (like in stock
brokering/financing).

These must have the possibility to transitioning to IPv6.

However, I must disagree with the proposal to require that their 
special requirements must have to be supported by IPv6 *tunneling* -- 
such enterprises also run routers which are feature-rich (as they're 
doing native v4 multicast) to support IPv6 -- there seems to be little 
excuse not to do that properly!

> +     through one or a few tunnel endpoints;

Isn't this quite a strong case for non-tunneled IPv6?  "Dense" 
deployment seems to call for better deployment model :)

> +  infrastructure costs are also required.

Doesn't this apply to every scenario ?!?! :)   

> +    Enterprise 3  N      -/*    *    -      *       -      *

I think "ISP" support in this is not applicable -- as in the other 
scenarios we're considering connectivity to the ISP -- here, it's not 
applicable.  Or maybe this would have to be reworded to be more 
general like "Infrastructure requirement" but not sure if that would 
make sense either.

I'm confused why you require security in one scenario but only have it 
as nice-to-have in others.

As already stated, I'm hesitant about adding multicast requirement 
here; however, I agree that this is something that might not hurt to 
evaluate.  If we had to specify a mechanism just to meet this 
scenario, I'm not sure if it would be have good ROI.

> +    6over4  N       Y      Y      R      Y      Y     Y      R     Y

(For the record, Dave is referring to RFC2529 with "6over4" :)

6over4 is Y@; 6to4 was already in in my working copy.

6over4 implementation is what I'd classify as R or R? -- I know of 
one, and I have seen no indication that this would get any better.  
Deployment R? or N? respectively..

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