[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
>
>