Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd)

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Thu, 07 Oct 2004 15:32:33 +0300

Hello,

<Chair hat on>
I'm wondering why there are no comments to this draft. To kick-off the
discussion I'm going to provide some of my own. However, please, comment
the draft! We cannot move forward if people don't comment!
<Chair hat off>

I'm not going to comment much on the details. As it is the first
version, I'm just trying to express my opinion on the general direction
of the draft.

First of all, there is a lot of information in the draft about how the
transition/deployment of IPv6 in enterprise environment is to be done.
However, the conclusions seem not to be clearly derivable from the text.
I think the goal of the document is to have clear conclusions what is
expected from the IETF to be done (nothing - everything is already done,
requirements for transition protocols/mechanisms, identifying the
protocol needed). 

I think this is somewhat in the document, but not clearly enough. So,
what I would like to see is more clearly the link between the actual
text of the document and the conclusions in the section 8. At least to
me it is not clear how the conclusions have been reached.

Cheers,

Jonne.
On Mon, 2004-09-27 at 12:29, ext Pekka Savola wrote:
> Folks,
> 
> (co-chair hat on)
> 
> There haven't been any reviews on the list.  That's not good.  We need
> the reviews to make this go forward.  Otherwise we cannot go forward
> with this, and we cannot go forward with the transition mechanisms for
> the enterprises.
> 
> PLEASE provide feedback ASAP!
> 
> (co-chair hat off)
> 
> ---------- Forwarded message ----------
> Date: Sat, 18 Sep 2004 21:24:32 +0300 (EEST)
> From: Pekka Savola <[email-masked]>
> To: [email-masked]
> Subject: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt
> 
> Hi,
> 
> (co-chair hat on)
> 
> This is the initial draft on Enterprise network analysis, and is still
> being improved.  We need input from the WG to make it better.  Please
> read and comment ASAP, preferably within a week.  We hope to get this
> in the shape for WG last call reasonably soon.
> 
> Again, please send feedback.  This is very important work!
> 
> (hat off)
> 
> 
> On Thu, 16 Sep 2004 [email-masked] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the IPv6 Operations Working Group of the IETF.
> > 
> > 	Title		: IPv6 Enterprise Network Analysis
> > 	Author(s)	: J. Bound, et al.
> > 	Filename	: draft-ietf-v6ops-ent-analysis-00.txt
> > 	Pages		: 30
> > 	Date		: 2004-9-16
> > 	
> > This document analyzes the transition to IPv6 in enterprise
> >  networks.  These networks are characterized as a network that has
> >  multiple internal links, one or more router connections, to one or
> >  more Providers, and is managed by a network operations entity.  The
> >  analysis will focus on a base set of transition units and
> >  requirements expanded from a previous Enterprise Scenarios
> >  document, and will depict a set of components and transition
> >  methods required for the enterprise to transition to IPv6 within
> >  each scenario and then common to all scenarios.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-00.txt
> [...]
> 
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Thu, 7 Oct 2004 15:17:43 +0100

> me it is not clear how the conclusions have been reached.

Hi Jonne,

I'm sure Jim can answer, but my $.2c

The idea was that we'd pump out a first draft quickly so people could
comment on its direction.  It wasn't meant to include all solutions.
So for example I wrote sections 4 and 7, others added other sections,
but without adding an analysis/recommendation on top.

Once we have agreement on direction (which should have happened on list
some time ago now, but noone commented) we could add the text for the
actual recommendations (section 8).

If you feel we should just press on in the absence of feedback, then let
the authors know.   Time to get a revised version in by 18th is running
out.

Tim

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Thu, 07 Oct 2004 18:21:42 +0300

Tim,

> but without adding an analysis/recommendation on top.

I understand and agree with the approach, of course.

> the authors know.   Time to get a revised version in by 18th is running

As nobody commented the document, I decided to comment first myself, and
then start to complain that other people do not comment. If nobody
comments, I guess you have to work forward and hope that people agree. 

Cheers,

Jonne.
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34

---

From: Heikki Vatiainen <[email-masked]>
Date: 11 Oct 2004 21:25:38 +0300

Here are my comments on the enterprise network analysis draft.  They
are based on our experience on enabling IPv6 on a part of our
university's network.  What we have been doing falls nicely under the
wide-scale dual-stack deployment category with work-arounds to cope
with routing infrastructure that is not IPv6 capable.

Here are the comments:

  4.4.2  Deploy a parallel IPv6 infrastructure
[cut]
  Such an approach means acquiring additional hardware, but it has the
  advantage that the existing IPv4 routing platforms are not disturbed
  by the introduction of IPv6.

I think dual stack has been available long enough that the potential
for disturbance is not great enough to justify a parallel
infrasturcture for IPv6.  In fact, I would recommend that parallel
infrasturcture is only built if no other options, such as upgrading to
dual stack routers, are available.

The problems we have noticed with running a parallel infrastructure
touch many areas.  I try to enumerate our findings in the following
paragraphs.

The parallel infrastructure forces you to have two times the
documentation about the network.  If e.g. intra-organization packet
filtering is done, you have to literally think and check twice that
the filters are set up as required.  With dual stack you may need to
create two sets of filters, one for IPv4 and one for IPv6, but at
least they apply to the same interface on the same router.

If the network is built using VLANs one can extend (trunk) the VLANs
to the new IPv6-only routers.  If the new IPv6 routers are physically
and/or network topologically close to the existing IPv4 routers, this
may be easy to accomplish.  The fourth paragraph discusses the use of
one router to serve many VLANs by "collapsing" them to one router
interface.  If the VLANs are not already topologically close to the
new IPv6 router one has to grow the existing VLAN coverage.  Nobody
wants to do this since this is yet another step to a VLAN spaghetti
network.

When thinking about the routers, IPv6-only router may cause
surprisingly many problems with network and router management.  Our
IPv6 only router does not do at least SNMP, Syslog or NTP over IPv6
transport.  One may think this is only a short term problem, but the
router is only half of the problem.  The other half are the management
applications that are used to monitor and manage the routers.  If dual
stack routers are used, management applications can use IPv4 transport
making the lack of IPv6 transport a less or even a non problem.

In conclusion, I think building a parallel IPv6 infrastructure
initially looks like a non-disturbing approach but a closer looks
shows that it does contains many issues that may cause disturbance
later on.  Finally, the last paragraph of 4.4.2 mentions that the
parallel approach should be viewed only as an interim step.  The
history shows that interim tends to become Integrated or permanent or
otherwise established, so why not use the resources to do dual stack.

  7.3.1 Obtaining external connectivity
[cut]
  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.  Use of
  6to4 also prevents the enterprise adopting aggregatable global IPv6
  addressing from the outset.

I think the stability and availability of 6to4 relays is more of a
problem than the availability of stable 6to4 prefix.  I do not see
enterprise chancing its IPv4 addressing and thus is 6to4 prefix very
often.

However, with 6to4 the enterprise is putting its reachability towards
non-6to4 IPv6 Internet into hands of the closest 6to4 relay operator.
This should not cause problems if the relay is well supported.  The
reachability from the non-6to4 IPv6 Internet back to the enterprise
depends on the relay closest to whoever someone from the enterprise
was communicating with.

I would prefer tunnel broker over 6to4 in the draft.

  7.5.2  Supporting remote access
[cut]
  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 see enterprise's user working off-site as someone who establishes a
VPN connection back to the enterprise.  When the VPN connection has
been established, the user gets an IP address from the enterprise and
all or some of the traffic is tunneled back to the enterprise over the
VPN connection.

Even if the user is behind a NAT he can still access 6to4 relay over
the VPN connection. The 6to4 relay could even use the well-known
anycast address if all traffic is tunneled or the route towards the
well known address can be set to point to the tunnel.

If the user does not have VPN access and NATs and other filters and
packet manglers cause problems then the enterprise should provide VPN
service for the user.  Advanced VPN implementations may support IPv6
over IPv4 VPNs directly making the need for remote access aid
non-existent.

-- 
Heikki Vatiainen                  * [email-masked]
Tampere University of Technology  * Tampere, Finland

---

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

> dual stack routers, are available.

Hi Heikki,

I think this is made clear in 4.2 and 4.3?

> least they apply to the same interface on the same router.

Yes, this sort of issue should be reflected in the draft.  However, we
are deploying this way and having (for example) two firewalls rather than
one is not a big issue; the firewalls are only implementing policy.
At this stage commercial IPv6 firewalls are still lacking (in our case
Nokia IP740 + Checkpoint FW).
 
> may be easy to accomplish.  

I'm not sure I follow this.  Do you refer to the fact that some equipment
has trunking limits on (the number of) VLANs?

> The fourth paragraph discusses the use of

For a large site this may be a concern.  In such cases the site can either

a) defer v6 deployment until their routing platform supports it

b) deploy IPv6 incrementally to parts of the network using a combination
   of tunnels and VLANs

c) use some sparse deployment technology like ISATAP

Given we want to run IPv6, and introduce it in a structured, managed way,
we have gone with (b).

> making the lack of IPv6 transport a less or even a non problem.

Yes, if dual-stack routers are available.

Note the parallel infrastructure could be dual-stack to the router, with
the interfaces injecting the RAs being v6 only.   If you want to deploy
IPv6-only WLAN today, you have to do that as no APs have v6 transport 
management (or do they?).

> otherwise established, so why not use the resources to do dual stack.

The "disturbance later on" should be a non-issue as the site can upgrade
to dual-stack on the infrastructure in its next procurement cycle.  The
parallel network is only a stepping stone (as would be ISATAP, tunnels,
or any other interim solution).

The text could emphasise that.

> enterprise chancing its IPv4 addressing and thus is 6to4 prefix very

Yes, that is what is implied in the text.
 
> depends on the relay closest to whoever someone from the enterprise

In our case JANET runs a 6to4 relay.  In fact, we run one for our staff
and students, which they can manually point to.
 
> I would prefer tunnel broker over 6to4 in the draft.

But the draft is talking about enterprise, not soho; thus I don't think
we should recommend either.  However, if one must be used of those two,
I would say a broker is better.   But a large enterprise will most
likely have an ISP that can offer a tunnel.
 
> all or some of the traffic is tunneled back to the enterprise over the

Yes, that is one solution; the text should have that added.  However,
many of our staff and students don't use VPN, or want to access IPv6
resources off-site, and thus a supported broker/6to4 relay is useful 
for them if their own (ADSL/cable) provider offers nothing.
 
> well known address can be set to point to the tunnel.

This requires some geekdom though.  Our students have no problem doing
this...
 
> over IPv4 VPNs directly making the need for remote access aid

Yes, we also offer this option, using IPv6 over and OpenVPN service.
 
Thanks for the good comments!

-- 
Tim