Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt

From: "Bound, Jim" <[email-masked]>
Date: Tue, 12 Oct 2004 00:53:20 -0400

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Oct 2004 14:57:41 +0200

Jim,

Thanks for your reply. Further comments where I think I need
to clarify (points where there is no more to say deleted):

Bound, Jim wrote:
...
> Sorry I cannot respond to such a general statement ok.  

Let me rephrase my concern. Somebody reading this draft without
the background knowledge of this WG will simply not realise
that the fundamental coexistence model is dual stack. They will
find themselves right in the discussion of the 13 scenarios
and think that they must pick one of them - but the first question
anyone should ask is "can I just do a straightforward dual stack
model?" I would argue that for the large majority of enterprise
customers the answer will be yes, except for the corner cases
where they will have to do something special. So I think the draft
needs to start out by saying this - either by inserting my Scenario 0
or by saying it in words.

I don't have this problem with draft-ietf-v6ops-ent-scenarios-05.txt,
which starts out with base scenario 1, widespread dual stack.

> Will continue to respond.  All these cases are real cases 

Not denying that they will all exist somewhere.

> and you or I or the IETF cannot second guess or mandate any transition to the enterprise.

No, but we can advise our customers on the simplest, cheapest solution.

> This ia really naïve view 

Yes. I think most enterprises would prefer it that way.

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

It's not only that. Enterprises are not going to voluntarily add IPv6
support if they perceive it as adding great operational complexity,
which is an ongoing cost. They will simply wait until it becomes simple.

> Not really reread the vlan discussion.

As far as I can see, that only splits the routing. As far as hosts,
DNS and middleware is concerned it's still a dual stack model.

> I can tell but they are all in ent scenarios doc.

True, I think my problem here is what I have said at the beginning of this
message.

...
> Nor should we and we do not intend to.

Well, I think then that we have to add it to
draft-vandevelde-v6ops-nap-00.txt, because it is one of the
first things enterprise network security managers will
ask about.

...
> I see both views.  Both are required.

As a matter of fact I agree with the recommendation; I just want
to avoid mischaracterization of 6to4. Of course, if you simply
can't find an ISP to support you properly, a tunnel broker or
6to4 would always be possible.

That's it for now.

     Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 14 Oct 2004 19:57:09 +0300 (EEST)

> which starts out with base scenario 1, widespread dual stack.

I have the same concern as Brian.

The authors note in the draft that there are a lot of combinations,
(like close to a hundred, I recall from IETF60) and listing them all
the matrix doesn't make sense.  That's OK.  What I was writing in my
review comment is that because the matrix shows a number [less than
all] of entries, it should be sufficiently clearly explained what
those rest are, and properly bring forward those ones that clearly
make sense even if that requires only relatively small amount of text.

For example, one approach I could see might be having two matrices:  
one for the "really common and simple" cases (which a lot of
enterprises would probably look for), and "more complex" cases which
require need to be analyzed in more depth, and solutions provided for.

That might be one way to clearly show that there are both very simple
approaches and and more complex/advanced approaches, without having to 
list every possible combination out there.  There might be other ways 
to do that as well.

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

---

From: Tim Chown <[email-masked]>
Date: Mon, 25 Oct 2004 02:39:18 +0100

> which starts out with base scenario 1, widespread dual stack.

Three points:

a) There are many deployment models, all valid ones.

b) Dual-stack is the one that most sites will follow, for the foreseeable
   future

c) IPv6 dominant has enough usage cases to be included

So I would agree with adding an ent-scenarios like wording to indicate that
dual-stack is the way to go for the more common sites, but there's more
to the analysis (IPv6 dominant was one of the three ent-scenarios scenarios
after all).

> which is an ongoing cost. They will simply wait until it becomes simple.

Absolutely, as per the othr email on parallel networking (as an example)
if you can upgrade that's great.  If you need to wait to a procurement
cycle, so be it, but many sites will want to jump in ahead of the commercial
availability, and that's where some of the interim methods described in
ent-analysis come in (else it is a short document :)
 
> DNS and middleware is concerned it's still a dual stack model.

Yes.  And that's the advantage, but deploying parallel now we get ahead of
the game for when we can slot in dual-stack routing infrastructure, and
we already have all our services IPv6-capable (and some interesting
experience from running v6-only on the parallel routing infrastructure).
 
-- 
Tim