Re: Enterprise scenario text proposal

[Pekka Savola <pekkas@netcore.fi>]

Thanks for your input.  A few comments inline..

On Thu, 18 Mar 2004, Dave Thaler wrote:
> ---
> 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.

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

> +  2. When NATs exist within the enterprise network, e.g., to connect
> +     branch offices to the corporate network.

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

> +  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.

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!

> +  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;

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

> +  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.

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

> 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      -/*    *    -      *       -      *

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.

> 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

(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