[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.]
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