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

[Tim Chown <tjc@ecs.soton.ac.uk>]

On Mon, Oct 11, 2004 at 11:00:23PM +0200, Brian E Carpenter wrote:
> 
> In other words, why would an enterprise choose to paint itself
> into any of the awkward corners of the other 13 scenarios?
> 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?

I think because there is no one-size solution.  I suspect that Scenario O
may be the most common though, but by how much, it's hard to tell.
 
> In fact, sections 4 and 7 are written in this spirit -
> they refer essentially to what I have shown above as
> secnario 0.

That is baed on our experience (in 6NET), but as Jim says others contributing 
to the analysis are doing things a different way and that experience is
being reflected.
 
> > 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.

Mea culpa.  Both references should have read as per 4.1, but it could better
say in both places:

  "In this document we do not discuss the deployment of Unique Local 
   IPv6 Unicast Addresses [ULA]."

> The simplest solution is to remove both these references to
> ULAs.

I would prefer to mention them, but just leaving it out is OK too.
 
> 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.  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.

That is what we did, so I would agree with adding such text.  However,
note (again as Jim said) this is a more Layer-3 oriented view, so beyond
basic services like DNS we shouldn't get lost in application space too
much.   (ISP, 3GPP and unmanaged alos stayed in Layer 3 I believe).
Otherwise it'll be a big document :)
 
> >  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.

Well, 6to4 and the tunnel broker *are* being used for both network and
single node access to remote sites.   If you want the text changed so
that 6to4 is only for networks, and the broker is for hosts or networks,
that's fine.   Just reporting actual usage...

6to4 is bad for a number of reasons, reliance on the relay being one.
Why use 6to4 or a broker for a large enterprise when a specific tunnel
can be set up?

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

Well, "apart from updating the prefix" menas a whole site renumbering
exercise, and that's uncessary pain when you can use 2001: space from an
ISP who is quite likely to be your future native IPv6 provider.
 
> > 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.

Fair point;  could cite both?
 
> > 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.

There seem to be a few people who think NAT-PT should live on (though I'm
not one of them, I felt the solution should be mentioned, but I personally
wouldn't put it in the recommendations section of the analysis - and that
WILL be a hot potato in this draft!).
 
> > 7.5.2  Supporting remote access
> >
> 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.

Yes, I agree we should add some IPv6 over IPv4-VPN text here.
 
Thanks for the comments Brian.

-- 
Tim