Classification: UNCLASSIFIED
Caveats: NONE
Brian,
I work for the military and would dearly love to go to a dual-stack everywhere, but as Jim mentioned, that's simply not feasible. Unlike commercial users, we typically must develop our own unique comms networks that support unique military requirements (i.e. extremely constrained bandwidth (we feel lucky to have 16KBPS "pipes"), unpredictable, but inevitable and often lengthy, disconnects from network services, and a need for both host and routing infrastructure to be mobile). In such an environment, operating two routing protocols, as you must with dual-stack becomes quite problematic. In addition, because of the lengthy life cycles of weapon systems (15-20 years), you find yourself working with processors that are overloaded already. Throw a dual-stack requirement on this tactical environment and you break the camels back.
So we are typically looking at replacing the entire tactical comms infrastructure. Given the other constraints on bandwidth, mobility, etc., it becomes very attractive to make the leap from IPv4 directly to IPv6 without a lengthy dual-stack transition period. However, that essentially creates an IPv6-only ISP supporting our weapon systems on the battlefield. Of course, this, in turn, comes with another set of problems, primarily for interoperablity with IPv4-based current systems and allies, but we hope by aggressively migrating the force to IPv6-dominance that these additional problems become manageable.
Vr,
Steve
-----Original Message-----
From: Bound, Jim [mailto:jim.bound@hp.com]
Sent: Tuesday, October 12, 2004 12:53 AM
To: Brian E Carpenter; v6ops@ops.ietf.org
Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt
Brian,
Responding to Pekka's draft tomorrow and others which is more difficult. But here is my response to you.
> 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?
Sorry I cannot respond to such a general statement ok. Will continue to respond. All these cases are real cases and you or I or the IETF cannot second guess or mandate any transition to the enterprise.
> 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?\
This ia really naïve view it don't work that way at all and your assumption is one as casual and many are looking at ways to reduce cost and thus the 13 scenarios.
>
> In fact, sections 4 and 7 are written in this spirit - they refer
> essentially to what I have shown above as secnario 0.
Not really reread the vlan discussion.
>
> I just don't get what are the drivers for the other
> 13 scenarios.
I can tell but they are all in ent scenarios doc.
>Why would an enterprise accept any of them, rather than beating on its
>suppliers for dual stack solutions?
Well because many of them have told us they are doing it. How about that for an answer. Every author is working on real deployment not fantasy abstractions. Don't shoot the messengers.
>
> 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.
I believe this is a partial bug the idea is to use global addresses within a distributed enterprise across a wide Internet. We need to just clean this up.
> The simplest solution is to remove both these references to ULAs.
That may be an option.
>
> 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.
Nor should we and we do not intend to.
> 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.
This draft is only dealing with Layer 3. Except in cases below like ALG/Proxy.
>
> Details:
>
> The summary at the end of section 1 doesn't mention section 7.
Will fix.
>
> > 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.
Not really we can mention them this is layer 3.
>
> > 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.
Thanks for your opinion we should discuss for sure.
>
> > 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.
Uh OH but good there will be strong disagreement. I am just editor.
I see both views. Both are required.
>
> > ...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.
Point was to not mix the two we can make that clear. Once ISP has IPv6 6to4 is not required.
>
> > 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.
Agreed.
>
> > 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.
In this case I agree because it is an "assist to layer 3". Good idea.
>
> > 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.
Good point.
>
> > 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.
I agree. DSTM is v4-in-v6 as a note.
>
> >
> >
> ======================================================================
> > |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.
Its not missing it is not clear.
>
> The issue with NAT-PT applies to the entries for "translation", all of
> which I would replace by "ALG/proxy."
Personally I agree we can discuss with all authors.
>
> > 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.
Maybe but it depicts a real use case not a partial or abstract one and we authors want it in the spec.
Thanks
/jim
>
> Brian
>
>
Classification: UNCLASSIFIED
Caveats: NONE