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

From: "Pouffary, Yanick" <[email-masked]>
Date: Mon, 24 May 2004 23:56:10 +0200

Hi 

Thanks for the review. Comments in-line.

Yanick

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pekka Savola
> Sent: Monday, May 24, 2004 2:23 PM
> To: [email-masked]
> Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt
> 
> On 12 May 2004, Jonne Soininen wrote:
> > Hi everybody,
> >
> > this is a WG Last Call for comments on sending 
> > draft-ietf-v6ops-ent-scenarios-02.txt, "IPv6 Enterprise Network 
> > Scenarios" to the IESG for consideration as Informational:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-
> 02.txt
> 
> Personal comments below.
> 
> Seems to be ready after a revision for clarifications etc.  -- in any 
> case, the most important thing is the _next_ document..
> 
> 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. 

> I also thought that section 4 could possibly be removed at this point.

> If it wouldn't be, there are a few clarifications I have scribbed up, 
> omitting them now..
> 

[YP] We all agree

> substantial:
> ------------
> 
> [Network Infrastructure Component 1, sect 3.2]
>     Enterprise Provider Requirements
>        - One site vs. multiple sites?
> 
> ==> do you refer to _geographical_ sites here, or something else 
> (e.g., in the multi6 WG sense)?  Maybe add 'geographical' here?
> 

[YP] ok

>        - Leased lines or VPN?
> 
> ==> spell out, e.g. to:
> 
>        - If multiple sites, how is the traffic exchanged securely
between
>          them?
> ...
>        - What is the IPv6 address assignment plan available
>          from the provider?
> 
> ==> this should possibly be spelled out a bit, like:
> 
>        - Do the provider(s) delegate a stable /48 prefix?
>          Does the enterprise need more?
> 

[YP] ok

> ...
>        - Will clients be Multihomed?
> 
> ==> 'clients'?  Spell out a bit, maybe like:
> 
>        - Is the enterprise multihomed?  Which multihoming techniques
are
>          supported by the Service provider?
> 

[YP] ok

> ...
> 
>        - Is there an external data-center?
> 
> ==> I think this needs to be spelled out a bit.  Did you mean like:
> 
>        - Would some enterprise server(s) be housed in the service
>          providers' data centers?
> 

[YP] ok

> ...
> 
> ==> add an additional requirement, like:
> 
>        - Is IPv6 available using the same access links as IPv4,
>          or differently?
> 

[YP] ok

> ...
> 
>    [Network Infrastructure Component 2]
> 
> ==> add a couple of requirements, like:
> 
>        - Are applications only run in the internal networks?

[YP] ok

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

> 
>    [Network Infrastructure Component 3]
> 
>       - Is a Tele-commuter work force supported?
> 
> ==> reword to be more generic, maybe like:
> 
>       - Is working remotely (e.g., through VPNs) supported?
> 

[YP] ok

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

>        - Is network mobility used or required for IPv6?
> 
> ==> This requirement seems to need a bit more spelling out, as it
isn't
> 100%
> obvious what you're referring to (MIPv6 vs NEMO?), what's the usage
case?
> 
>        - What are the requirements of the IPv6 address plan?
> 
> ==> maybe add a couple of clarifying points here:
> 
>        - Is there a detailed asset management database, including
hosts,
>          IP/MAC addresses, etc.?
>        - What is the enterprise' approach to numbering geographically
>          separate sites which have their own Service Providers?
> 

[YP] ok - may be

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

>   Network Infrastructure Component 4
>     Enterprise Network Management System
>        - Performance Management Required?
>        - Network Management Applications Required?
>        - Configuration Management Required?
>        - Policy Management and Enforcement Required?
>        - Security Management Required?
>        - Management of Transition Tools and Mechanisms?
> 
> ==> these should probably be spelled out a bit more, because at least
I
> didn't have much idea what all of these included?
> 
> [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.

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

>      - All routers and switches are upgradeable to IPv6.
>      - Existing firewalls can be upgraded to support IPv6 rules.
> 
> ==> are these mainstream scenarios?  What does a switch's IPv6 upgrade
> mean
> (is it L3 switch? or management functions?)
> 
>      - IPv4 Private address space is used within the enterprise.
> 
> ==> the enterprise already had PI space (from the above), but still
uses
> private address space internally -- any particular reason why?
> 

>   DNS will now have to support both IPv4 and IPv6 DNS records and the
>    enterprise will need to determine how the DNS is to be managed and
>    accessed, and secured.  The range of DNS operational issues are out
>    of scope for this work. [...]
> 
> ==> here, it would be good to refer to
> draft-ietf-dnsop-ipv6-dns-issues-07.txt, and possibly add at the end
> something like:
> 

[YP] ok

>   These operations include at least:
>     - configuring IPv6 DNS servers as resolvers on IPv6(-only) hosts,
>     - selecting a method to insert AAAA/PTR records in the DNS,
>     - managing the DDNS reverse/forward updates processes, if used,
>     - providing IPv6 transport capability in the recursive internal
>       DNS servers, and
>     - managing the IPv6 capability in the authoritative servers, and
>       configuring the AAAA records at the delegator of the DNS zones.
> 
> ....
> 
>    The choice of interior routing protocols have an impact on how the
>    routing tables will be handled: some such as OSPF will have the
>    ships-in-the-night paradigm, others such as ISIS are integrated.
This
>    has an impact on the topology and the management of the network.
> 
> ==> I don't really understand what you mean with the sentence about
OSPF
> vs
> ISIS.  Do you mean that w/ OSPF you'd use separately OSPFv2 and
OSPFv3,
> and with IS-IS just one process?
> 
> Note that this discussion could probably be just a summary of
> draft-ietf-v6ops-isp-scenarios-analysis-02.txt section 4.3.1 and the
> Appendix A. (We should refer to that document here at least.)
> 
>    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.

> ==> maybe add at the end add something like:
> 
>   Decisions wrt. routing include at least:
>    - whether IPv4 and IPv6 routing topologies will be different,
>      affecting the decision on which routing protocols to use,
>    - how redundancy is ensured if tunneling is used, and
>    - which tools are to be used to monitor the IPv6 infrastructure.
> 

[YP] ok

> 5.3  Autoconfiguration
> 
>    IPv6 introduces the concept of stateless autoconfiguration in
>    addition to stateful autoconfiguration.  The enterprise will have
to
>    determine the best method of autoconfiguration, for their network.
>    The enterprise will need to determine if they are to use stateless
or
>    stateful autoconfiguration, and how autoconfiguration is to operate
>    for DNS updates.  The enterprise will need to determine how prefix
>    delegation is done from their upstream provider and how those
>    prefixes are cascaded down to the enterprise IPv6 network.  The
>    policy for DNS or choice of autoconfiguration is out of scope for
>    this document.
> 
> ==> this section should probably be generalized to be something like
> 'Configuration of Hosts [or: .. of Infrastructure and Hosts]'
> (and generalize the autoconfiguration a bit more
> in the rest of the paragraph as well)

[YP] ok

> ==> remove ", for their network", as everything is done for their
network
> in
> any case.
> ==> dynamic prefix delegation inside the enterprise may not be a
really
> feasible option, but in any case,  I'd probably add something like:
> "; the choices are to do this manually, or using a dynamic protocol"
> to better spell it out.
> ==> One might consider adding at the end something on whether an asset
> management database is being used, and the choices for configuring
other
> information on the hosts (e.g., DNS servers, proxy servers, etc.etc.).
> 

[YP] We will try to rework this

> 5.4  Security
> 
>    Current existing mechanisms used for IPv4 to provide security need
to
>    be supported for IPv6 within the enterprise.  IPv6 should create no
> *  new security concerns for IPv4.  The entire security infrastructure
> *  currently used in the enterprise needs to be analyzed against IPv6
> *  deployment effect and determine what is supported in IPv6.  Users
>    should review other security IPv6 network infrastructure work in
the
> *  IETF and within the industry on going at this time.  Users will
have
> *  to work with their platform and software providers to determine
what
> *  IPv6 security network infrastructure components are supported. The
>    security filters and firewall requirments for IPv6 need to be
>    determined by the enterprise. The policy choice of users for
security
>    is out of scope for this document.
> 
> ==> there is considerable overlap with two sentences above, marked
with
> '*'.
> I suggest removing one of them and expanding the other slightly.
> 
> ==> you should probably refer to some security documents here, e.g.,
> draft-savola-v6ops-security-overview-02.txt
> 
> ==> add at the end maybe something like:
> 
>    At the very least, one has to consider for example:
>      - whether the same access control/IDS policies are to be used for
>        IPv6 as with IPv4, and whether these are to be handled by the
>        same or different equipment/software,
>      - how keying and/or certificates are managed,
>      - how VPNs are controlled,
>      - whether RFC3041 temporary addresses are to be used and to
>        what extent if so,
>      - whether there are to be internal access control points, and
>      - if tunneling techniques are used, how this affects the site
>        security, and how site must be secured to make tunneling
secure.

[YP] ok

> 5.6  Network Management
> 
> 
>    The addition of IPv6 network infrastructure components will need to
>    be managed by the enterprise network operations center.  Users will
>    need to work with their network management platform providers to
>    determine what for IPv6 is supported during their planning for IPv6
>    adoption, and what tools are available in the market to monitor the
>    network.
> 
> ==> remove 'in the market' -- appears redundant here?
> ==> maybe add something like:
> 
>    At least, one should consider:
>     - whether IPv6-capable devices can be managed or monitored using
>       IPv4, and what must be done if that is not possible, and
>     - how IPv6 infrastructures are being monitored?
> 
> 
> 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.

> ==> in any case, I think there is one thing that should be explicitly
> called
> out: Whether the site wants to consider whether this new kind of local
> addressing is used for v6 or not.
> 

[YP] ok

>    For inter-domain use, sites may choose to migrate IPv4 multicast
>    applications to SSM, for which no reverse path discovery method is
>    required.
> 
> ==> ", for ..." part is incorrect and out of context, replace with
> something
> like: ", which simplifies the multicast architecture, but requires
that
> the
> applications specify the multicast transmission source(s).
> 
> ==> Maybe add a new paragraph:
> 
>    The enterprises also need to consider whether IGMP/MLD snooping or
>    similar solutions to reduce the multicast flooding is
>    required: this may be especially important if the subnets are
large,
>    or multicast is used extensively.
> 
> 5.9 Multihoming
> 
> 
>    At this time, current IPv6 allocation policies are mandating the
>    allocation of IPv6 address space from the upstream provider. If an
>    enterprise is multihomed, the enterprise will have to determine how
>    they wish to support multihoming.  This also is an area of study
>    within the IETF and work in progress.
> 
> ==> I think it would be appropriate to describe RFC3178 model of
> multihoming
> very briefly, e.g., like in section 5.6 in
> draft-ietf-v6ops-isp-scenarios-analysis-02.txt
> 

[YP] ok

> 7.  References
> 7.1  Normative References
> 
>    None at this time.
> [...]
> 
> ==> please add a lot more explicit informative / normative references
to
> the
> subject which were discussed.
> 

[YP] ok
> 
> 
> semi-editorial
> --------------
> 
> [Scenario 2 in sect 3.1]
>     Scenario 2: Enterprise with an existing IPv4 network wants to
deploy a
>                 set of particular IPv6 "applications" (application is
>                 voluntarily loosely defined here, e.g. peer to peer).
>                 The IPv6 deployment is limited to the minimum required
to
>                 operate this set of applications.
> 
> ==> I don't think it's good to say "minimum" here, because there is no
> reason to restrict it to the absolute minimum required.  The point
here is
> just that v6 deployment doesn't need to be _larger_ than required to
> operate
> the set of applications.
> 
> Maybe reword: s/is limited to/does not need to be more extensive than/
> 

[YP] ok

> editorial
> ---------
> 
> IPv6 Enterprise Network Scenarios
> 
> ==> maybe rename to something like 'Enterprise Networks IPv6
Transition
> Scenarios' to be more in line with the rest of the document?
> 
>    Enterprise Network    - A network that has multiple internal links,
>                            one or more router connections, to one or
> more
>                            Providers and is actively managed by a
> network
>                            operations entity.
> 
> ==> align the text for those lines which were broken to multiple lines
> by originally too many chars/line? (same also later)
> 
>    Provider              - An entity that provides services and
>                            connectivity to the Internet or
>                            other private external networks for the
>                            enterprise network.
> 
> ==> isn't 'Provider' a slightly too terse (and ambiguous) term?
> Maybe 'Service Provider' or abbreviated SP if necessary, instead?
> 
>    IPv6 only             - A node or network capable of supporting
only
>                            IPv6.  This does not imply an IPv6 only
>                            stack, in this document.
> 
> ==> the last sentence should probably be reworded to be clearer.  Did
you
> mean something like:
>                                   In the context of this document, a
>                            dual-stack node which has disabled IPv4 is
>                            considered IPv6 only.
> 
> 3.2  Scenarios Network Infrastructure Components
> 
> ==> reword to: 'Network Infrastructure Components for Scenarios' ?
> 
>           - Are the nodes moving within the enterprise network?
>            - Are the nodes moving outside and inside the enterprise
>              network?
> 
> ==> these should probably be shifted left about 3-4 spaces?
> 
>      - The DHCP server to update naming records for dynamic desktops
> uses
> 
> ==> reword maybe to:
> 
>      - The DHCP server updates the DNS records for dynamic desktops
>        with DDNS.
> 
> Document Acknowledgments
> 
> ==> s/Document //
> 
> Authors-Design Team Contact Information
> 
> ==> maybe reword to "Authors' Addresses" as it's the regular format?
> 
> ==> this is pretty long.  Two possibilities to summarize this a bit:
>  a) add an "Editor's Address" section, with just Jim's contact info,
in
> full; Keep "Authors' Addresses" section for the rest, but mention only
> names, affiliations and the email addresses.
>  b) just take out other info for the non-editors as names,
affiliations
> and
> email addresses.
> 
> 
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 

Thanks
Yanick

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 May 2004 09:09:52 +0300 (EEST)

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

> [YP] I agree with Richard Graveman to keep this example. Please send

will do in a separate message.

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

> [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 ?

> [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.
 
> 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.)
 
> 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. ?

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

> 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

could be reworded to something like:

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

---

From: Tim Chown <[email-masked]>
Date: Wed, 26 May 2004 22:23:25 +0100

I agree with Yanick's points in line (the ones that aren't just "OK" :)

Tim