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

From: Jonne Soininen <[email-masked]>
Date: 12 May 2004 18:20:11 +0300

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

Please review these documents, and send your feedback to the
list.  Please also indicate whether or not you believe that this
document is ready to go to the IESG.

The last call will end in two weeks, on May 26th.

Pekka & Jonne

---

From: Alain Durand <[email-masked]>
Date: Wed, 12 May 2004 13:30:32 -0700

> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios 

I think that the document has matured a lot, however
I'm a bit puzzled by section  4, and specially 4.2 & 4.3 that I found  
not very well
articulated.

4.2  IPv6 Tunnels to Encapsulate IPv4

    An IPv6 capable node, on an IPv6 link within an IPv6 routing domain,
    wants to communicate with a legacy IPv4 application.

==> I'm not sure how an IPv6 over IPv4 tunnel by itself is going to  
solve this,
         unless you assume a model like DSTM where the v6 node and  
applications
         are v4 aware,  but the infrastructure is not.... This is not  
spelled out in the scenario.

         In other words, I think 4.2 is not describing a scenario but  
showing a solution.

4.3  IPv6 only communicating with IPv4

    An IPv6 capable node wants to communicate with an IPv4 service, but
    the node is operating as IPv6 only.  In order to continue support for
    communications with IPv4 services an IPv6 to IPv4 translator or IPv6
    proxy is required.  Introduction of such software may prevent usage
    of end-to-end security trust models and applications carrying
    embedded IP addressing information.  Bi-directional establishment of
    connections might be difficult to achieve.

==> somehow similar comment, this is solution space, not scenario space.

So I believe that section 4 is not quiet ready and should describe the  
problem more,
that is, from what I understand, how to interoperate between v4 & v6  
services (not nodes),
or more specifically, how to access legacy v4 service.

the 3 sub-cases are IMHO:

a) v4 only or dual stack client app on dual stack node in dual protocol  
network accessing a v4-only service
   (solution hint: use the v4 stack.)

b) v4 only or dual stack client app on dual stack node on mono protocol  
v6 network accessing a v4-only service
     i.e. the network on which the client sits has no IPv4 native routing
   ( solution hint: use the v4 stack, but tunnel v4 over v6 to regain  
IPv4 connectivity)

c) v6 only client app accessing a v4-only service
    (solution hint: failure or translation or relay)

There is of course the reverse scenario, of legacy v4 clients accessing  
new v6 services.

The real challenge of this document is now to explain in each of the  
example scenarios which of those cases
really apply and thus MUST be solved, versus saying everything MUST be  
solved.

So, as a conclusion, I think that section 4 is not ready for  
publication.
Note: I think the rest of the document is. Would removing section 4  
entirely be an option?

	 Alain.

---

From: Tim Chown <[email-masked]>
Date: Wed, 12 May 2004 23:49:42 +0100

I believe this is ready.

Alain's point is valid, but I don't believe changes would impact the
usefulness of the draft as is.   If section 4 were removed a requirement
subsection would be needed in section 5 to state that legacy interworking 
is required for four main modes: 

a) dual-stack <-> v4 or v6 only
b) v4 only <-> v6 only
c) v4 <-> v4 over v6 infrastructure
d) v6 <-> v6 over v4 infrastructure

But this is good.  It's time to move on and document the analysis.

Tim

---

From: Pekka Savola <[email-masked]>
Date: Mon, 24 May 2004 15:23:04 +0300 (EEST)

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

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

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?

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

...
       - Will clients be Multihomed?
 
==> 'clients'?  Spell out a bit, maybe like:

       - Is the enterprise multihomed?  Which multihoming techniques are
         supported by the Service provider?

...

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

...

==> add an additional requirement, like:

       - Is IPv6 available using the same access links as IPv4,
         or differently?

...

   [Network Infrastructure Component 2]

==> add a couple of requirements, like:

       - Are applications only run in the internal networks?
       - 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?

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

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

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

...

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

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

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

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

  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.

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

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

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.

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

   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

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.

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/

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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 24 May 2004 15:29:07 +0300 (EEST)

> d) v6 <-> v6 over v4 infrastructure

Isn't this a list of all the possible combinations?

The point here is, do we need to care for all of these combinations?  
For example, in the unmanaged networks, b) was considered out of
scope, and that's also recommended against in the 3GPP.  c) is also
something that I'm not sure there is yet consensus whether this is a
reasonable approach at this point.

One goal of the scenarios/analysis work is to try to identify the
actual, critical, mainstream scenarios which call of certain kind of
interworking or mechanisms.  I think at least a) or d) fulfill these
criteria, but b) and c) might be so-and-so, depending on how you
phrase it and which kind of techniques one might have in mind
applying..

---

From: [email-masked]
Date: Mon, 24 May 2004 09:01:31 -0400 (EDT)

Pekka,

> is not replaced by something else.]

OTOH, some of these networks are large, and they buy a lot of equipment,
so some major vendors take their requirements quite seriously. Therefore,
I would be against dropping this case. We can discuss further whether this
is exactly the right characterization, however.

Regards, Richard

---

From: Jonne Soininen <[email-masked]>
Date: Mon, 24 May 2004 23:16:30 +0300

Hi Pekka,

these are scenarios and the scenarios should describe the possible
scenarios that do make technically sense and hence, are possible to be
deployed. I do not see why not all of the scenarios would not make
sense. 

Cheers,

Jonne.

---

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

On Mon, 24 May 2004, Jonne Soininen wrote:
> scenarios that do make technically sense and hence, are possible to
> be deployed. I do not see why not all of the scenarios would not
> make sense.

Enumerating the possibilities is of course fine.

I was mainly objecting to Tim's wording:

  If section 4 were removed a requirement subsection would be needed in
  section 5 to state that legacy interworking **is required** for four
  main modes:

(emphasis mine)

s/is required/needs to be considered/ (for example) and it would be
fine by me..

---

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

> is exactly the right characterization, however.

I can see the argument why this needs to be considered .. money is a
language everybody understands .. but I'm concerned that this would be
painted as a "model" for v6 deployment, i.e., that other enterprises
which have very little in common with such defense networks would
start mimicking their deployment strategies just because those are the
ones described in our documents.  This is why I'm worried about 
keeping this here.

But let's hear if there are more opinions about this.

In any case, if it stays, this could probably be clarified a bit, 
like:

   A Security Defense Network Operation:
                                                                                  
==> add here something like:

    Note that these kind of networks are uncommon and unfit to be a
    model or example for deployment for enterprises in general.  
    However, due to their importance to the vendor community, their
    requirements should be considered explicitly.

...

     - External network required at secure specific points.
 
==> I had hard time parsing this, "at secure"?  Did you mean:

     - External network is required, but only at specific, secure, 
       exit points.
 
...

     - Network must be able to absorb ad-hoc creation of sub-Networks.
 
==> I didn't quite understand what this meant, please clarify.  (I've 
a hunch, but..)

     - Entire parts of the Network are completely mobile.
 
==> are we talking about a mobile network (NEMO sense), or nomadic 
network (network de-attaches, moves, network re-attaches) ?  The 
latter would at least be feasible, while the former may be a bit more 
problematic.  Maybe worth clarifying a bit..

     - Network must be able to bolt on to the Internet to share
       bandwidth as required from Providers.

==> "bolt on to the Internet" ?  I wasn't sure what this was trying to 
say -- that the network must be able to multihome for load-sharing 
purposes, or...?

     - Nodes must be able to access IPv4 legacy applications over IPv6
       network.

==> are these internal legacy apps, external ones, or possibly both?  
Isn't this assumptive about IPv6 deployment ("v6-only") and unfit for
requirements?

---

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

Hi Pekka,

I think all four cases should be considered.

Whether you consider b) and c) depends on whether you think an IPv6-only 
nodes will be deployed or IPv6-only network infrastructure might be deployed.
I think both are happening in some networks now.  Not many, but it is
happening and that volume will only grow, so we should cater for it.

I agree a) and d) are mainstream, and perhaps the wording can reflect that,
but we should consider all four possibilities in ent-scenarios.

Tim

---

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

Pekka,

I think ent-scenarios as a draft has been floating around for some time, and
anyone could have offered new or different scenarios if the ones included
weren't deemed representative.  I'm not sure that changing a scenario would 
make a significant difference.

The draft is a difficult one.  The scope is simply *huge*, and thus the text
can always be expanded or improved.   I think what we have, and the specific
scenarios, are good enough.    Let's move on.

Regards your queries, the meanings seem clear to me, re "at secure", "ad hoc
creation" and "bolt on".   The language could perhaps be expanded, but I don't
think the meaning is ambiguous, so again let's move on?

I do plan to write up a campus scenario (and analysis) separately (so I
don't hold up the main thrust), which will be drawn from 6NET experience
(you can look at D2.3.3-bis from 6NET yourself if curious as to the nature
of that scenario text).

Tim