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

From: "Bound, Jim" <[email-masked]>
Date: Tue, 12 Oct 2004 01:05:42 -0400

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

That is not the objective.  Users will use the capability of dual stack
in different ways and we are addressing all those ways.  To not do that
is not useful one-size-does-not-fit-all for transition.

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

Agreed and you just provide the exact operational business case for Ipv6
Dominant network transition and the market and users are seeing this
now.  The faster they move to IPv6 the quicker the deployment of the
reason they want IPv6 and at a reduced cost.  Thanks for helping that
case.

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

This is valid in my view but the flip side is what is the cost to drop
extended vlan boxes into the network and then add the tags to reach
those routers.  Your only then touch two points on your network and
minimal cost to add a complete IPv6 site theoretically????????????

> 
> When thinking about the routers, IPv6-only router may cause 
> surprisingly many problems with network and router management.

Hmm we assumed no IPv6 only anything?  But rather use of IPv6 dominantly
over IPv4?

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

Hmmm I did not know of IPv6 ONLY router?  But generally I agree with you
and so does the draft?

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

I think we need to clean up the word parallel we were not using it this
way so you found a bug.  Thanks.

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

I think I agree.  Every user I know that wants to use IPv6 have obtained
or are obtaining IPv6 prefixes and in that case 6to4 is not required.
Tunnel Broker plays well to legacy systems to reach IPv6 applications.

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

Well stated.

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

We have ended up there too.  But we all need to discuss.

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

This is the case where 6to4 could be requried by the enterprise at least
at the edge then it just becomes an 2002 prefix address.  Good point.

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

Yes.

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

Or just use Teredo and the Enterprise can support Teredo Server/Relay
too.

Thanks
/jim

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

---

From: Heikki Vatiainen <[email-masked]>
Date: 14 Oct 2004 18:33:26 +0300

> is not useful one-size-does-not-fit-all for transition.

I agree that one size does not fit all.  My point was to remind that
if no IPv6-capable existing routing infrastructure is available, one
simple possibility is to consider upgrading to such an infrastructure.
This is what section 4.4 or its subsections are not currently
mentioning.  Currently the draft makes building parallel IPv6
infrastructure to look fairly simple when I think it is not.

My current opinion is to prefer upgrade to dual stack over building
parallel if those are the choices and if there are resources to do the
both and no special reason to select one over the other. When I wrote
the original paragraph, I had dual stack vs parallel in mind.

> reason they want IPv6 and at a reduced cost.  Thanks for helping that

Ok, that works for IPv6 Dominant Network Deployment too.  My original
thought was to reduce the effort by not building parallel infra.  One
way to achieve that is to go IPv6 dominant.  I have to admit I did not
think IPv6 Dominant very much when reading the draft since it feels
like a option that is very much in the future.
 
> minimal cost to add a complete IPv6 site theoretically????????????

This would, in other words, be the so called "router-on-a-stick"
configuration to route IPv6 between VLANs?

This configuration would allow minimal cost IPv6 coverage if the VLANs
are easily available where the IPv6 router is put to.  E.g. here that
is not the case, since we have quite a number of IP subnets, and
respectively VLANs, and effort is made to keep the VLANs as local as
possible.  If we would route IPv6 between all or even most of the
VLANs with a "router-on-a-stick" method, we would have to give up this
VLAN locality and that would cause plenty of resistance.  It is not
seen as simple and secure to have all VLANs available on every campus
Ethernet switch.

> Hmm we assumed no IPv6 only anything?  But rather use of IPv6 dominantly

I was thinking IPv6 only router when building a parallel IPv6
network. The first paragraph of section 4.4.2 mentions the possibility
of IPv6 only routing.

> Hmmm I did not know of IPv6 ONLY router?  But generally I agree with you

We took a commercial router, as opposed to using a linux or bsd
router, and experimented with building parallel IPv6 routing using a
router that has IPv4 routing disabled.  IPv6 routing works very well,
but the router management was quite heavily tied to IPv4.

Thanks,

---

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

> infrastructure to look fairly simple when I think it is not.

But 4.2 and 4.3 state this reasonably clearly?   Perhaps removing
the word "existing" would make it clearer?
 
> the original paragraph, I had dual stack vs parallel in mind.

Of course.
 
> like a option that is very much in the future.

Our (my) view is to deploy dual-stack with IPv6 capbility in all (or as
much as possible) of the infrastructure to enable IPv6-only nodes to
be deployed, and a gradual phase over to IPv6 dominant.   

However, one scenario in the analysis is IPv6 dominant from the start,
and so we must cater for that too.
  
> If we would route IPv6 between all or even most of the

And there will be some equipment that does not support VLANs, so it is
not a perfect solution by any means.  But for some (many?) people it will
be good enough (the method is widely used in those European universities 
that are deploying IPv6).
 
> network. The first paragraph of section 4.4.2 mentions the possibility

Yes, that is what we do.   As a bonus we also gain experience in IPv6-only
networking for future wider deployment.
 
> but the router management was quite heavily tied to IPv4.

Yes, this is the case with many commercial products today (but not all!)
and is an issue to be resolved in due time.
 
-- 
Tim