RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt

[Pekka Savola <pekkas@netcore.fi>]

On Mon, 24 May 2004, Pouffary, Yanick wrote:
> Thanks for the review. Comments in-line.

A few remainders inline..

One thing I forgot in the review: Network Infrastructure Component 3
-- What network operations software will be impacted by IPv6? should
probably also include 'Backup/restore software(s) used' (or something
like that).  At least in our enterprise, we're using a network-based
backup software which cannot be proxied/translated, and if we want to
do backups, we'd stuck with IPv4..  It might be good to raise this out
explicitly in case this would turn out the be a issue.  Another
possible consideration in the same category would be file-sharing
(NFS, CIFS, etc.) from centralized file servers to other servers, if
that's being done.  

> > I think Example network C, a security defense network, is not 
> > mainstream enough to be applicable to be investigated in the 
> > scenarios.  There are probably 1, 5 or 10 such networks in the world. 
> > We should be focusing on more common scenarios (even addressing 
> > "80/20" would be good).  [I have a few specific comments for 
> > clarification within this example, but I'll send them if this example 
> > is not replaced by something else.]
> > 
> 
> [YP] I agree with Richard Graveman to keep this example. Please send
> you're your comments. 

will do in a separate message.

> >        - Are ALGs or proxies being used for some applications?
> >          Would using such be feasible?
> >        - Are there applications which cannot be proxied or
> >          upgraded to support IPv6?
> 
> [YP] I think we have this already covered.

I'm not sure if I see that.  I think there are two related, more
generic points:

       - Can the application be upgraded to IPv6?
        - Do the applications have issues with NAT v4-v4 and NAT v4-v6?

.. but these (IMHO) may not spell it out sufficiently to the reader.  
In the end, I think the the two points I proposed are good, because:

 a) it raises the question whether proxies are already being used, or
whether using them would be feasible.  If that's the case, application
transition is significantly easier, as one can interoperate between v4
and v6 using the proxies (if the enterprise network's goal is to move 
predominatly to v6).

 b) the second raises the question about the "remainder apps" for
which some other, more difficult strategy must be considered.  It
would be good if the enterprises would have to map these themselves..

> >        - Is inter-site communications required?
> > 
> > ==> I don't quite understand this requirement, because I fail to see
> _any_
> > scenario where you wouldn't need to communicate between sites?  Could
> you
> > clarify?
> > 
> 
> [YP] The enterprise may want to deploy IPv6 within a single site.

Oh ok -- maybe reword to something like: "Would IPv6 be deployed on 
multiple geographical sites?" or the like ?

> > ...
> > 
> >       - What will be the IPv6 Security policy/procedure?
> > 
> > ==> there should probably be a bit more on this..? maybe at least
> like:
> > 
> >       - Are separate or same firewalls, IDS systems, etc. used for
> IPv6?
> >         Which part of the traffic is encrypted using IPsec and how?
> > 
> 
> [YP] your clarifications are useful but do we need to be that specific?

That's a good question.  My interpretation of the current list is that 
it's purpose is to wake up the thinking process of the enterprise 
managers and/or transition planners.  If the points are generic, it 
may be that these wouldn't spark thoughts.  On the other hand, if one 
could go through the list similar to a "checklist", it would be easier 
not to forget anything important.

In that light, it would probably be useful to add "pointers" 
triggering the people to think about the details.. as long as it 
doesn't get too detailed.
 
> > [Example Network A, sect 3.3]
> > 
> >      - ISP does not offer IPv6 service.
> >      - Private Leased Lines no Service Provider Used
> > 
> > ==> is the first really often the case?  If you're a suffiently big
> > enterprise, I think at least in Europe there are already quite a few
> ISPs
> > willing to give you service. (note: s/ISP does/ISPs do/ .. as it has
> > multiple ISPs?)
> 
> [YP] yes it is the case. We have a lot of enterprises out there which
> are far behind with regard to internet revolution.

OK.. I guess such enterprises will be out of luck wrt. external IPv6 
connectivity unless an ISP in their area is willing to provide it. 
(IMHO, using e.g. 6to4 to get connectivity is not good enough for 
enterprises.)
 
> > ==> I don't quite understand the second bullet point?  do you mean
> that
> > the
> > site has just one ISP, and the rest are connected using leased lines
> to
> > the
> > "primary" ISP, and they don't have a direct connectivity at all?
> > 
> > I'm not sure if this is any longer the "mainstream" scenario, because
> the
> > net traffic is probably so high that the enterprises don't want to pay
> > $$$$
> > for transporting all their traffic to their HQ using leased lines, but
> to
> > throw it out to their ISP immediately (and tunnel internal traffic
> with
> > VPNs, or leased lines).
> 
> [YP] I don't agree. Yes this is a cost issue hence why they are looking
> at deploying IPv6 as a replacement solution.

I'm not sure if I understood your point.  Did you mean ("replacement
solution") that by deploying IPv6, they'd also get rid of the leased
lines, or start doing VPNs, etc. ?

> >    IPv6 capable routers should be monitored to ensure the router has
> >    sufficient storage for both IPv6 and IPv4 route tables.  Existing
> >    network design principles to limit the number of routes in the
> >    network, such as prefix aggregation, become more critical with the
> >    addition of IPv6 to an existing IPv4 network.
> > 
> > ==> I do not think monitoring the routers for sufficient v4/v6 route
> > table storage is an operationally important issue, clearly not more
> son
> > than
> > monitoring v4 route tables today, at least.  Maybe just remove this
> first
> > sentence or even the whole paragraph.
> 
> [YP] Exactly the point is you need to do the same. I think we should
> keep the paragraph as is.

OK -- but I think the paragraph should make it clearer that this is
not an IPv6-specific issue; in other words:  If the enterprise is
already doing it, they're encouraged to keep doing it.  If they aren't
doing it, there's no strong incentive to start doing it now.

> > 5.7  Address Planning
> > 
> >    The address space within the enterprise will need to be defined and
> >    coordinated with the routing topology of the enterprise network.
> It
> >    is also important to identify the pool of IPv4 address space
> >    available to the enterprise to assist with IPv6 transition methods.
> > 
> > ==> I don't think the "pool of IPv4 address space" is all that
> > relevant consideration here, as it hints at the use of IPv6-only
> > infrastructures, NAT-PT, and the like.
> 
> [YP] don't agree. The availability of IPv4 address space will trigger
> the choice of deployment techniques. It is very relevant.

I don't dispute the availability of IPv4 address space, but IPv4 
address space dedicated to transition methods :).  So maybe this:

   It
   is also important to identify the pool of IPv4 address space
   available to the enterprise to assist with IPv6 transition methods.

could be reworded to something like:

   The amount of available and used public IPv4 addresses is an
   important factor when considering the deployment techniques.

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