[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd)
Good comments and good response. One important point to note that was
noted to Pekka in my response. No one is assuming an IPv6 ONLY anything.
The entire spec assumes dual stack. What we do believe is users will
move services and routing to IPv6 and not IPv4 on points of the network
in several cases immediately as part of the transition and definitely as
a plan. This does not imply IPv6 only but dominant use of IPv6.
/jim
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tim Chown
> Sent: Sunday, October 24, 2004 9:06 PM
> To: v6ops@ops.ietf.org
> Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd)
>
> On Mon, Oct 11, 2004 at 09:25:38PM +0300, Heikki Vatiainen wrote:
> >
> > 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.
>
> Hi Heikki,
>
> I think this is made clear in 4.2 and 4.3?
>
> > 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.
>
> 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).
>
> > 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.
>
> 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 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.
>
> 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).
>
> > 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.
>
> 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?).
>
> > 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.
>
> 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.
>
> > 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.
>
> Yes, that is what is implied in the text.
>
> > 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.
>
> 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.
>
> > 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.
>
> 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.
>
> > 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.
>
> This requires some geekdom though. Our students have no
> problem doing this...
>
> > 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.
>
> Yes, we also offer this option, using IPv6 over and OpenVPN service.
>
> Thanks for the good comments!
>
> --
> Tim
>
>