[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Enterprise scenario text proposal
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