Subject: Comments on draft-ietf-v6ops-ent-scenarios-00

From: Tim Chown <[email-masked]>
Date: Sat, 18 Oct 2003 12:58:54 +0100

Hi Jim,

Here are some (long) comments on draft 00.  I am sorry they are later than 
ideal but I hope they are still useful prior to Minneapolis.

The document is absolutely on the right track, in my view.  The detail of
comments is mainly for clarification :)

The introduction generally reads very well and sets the scene nicely.

>    Each enterprise will select the transition that best supports their
>    business requirements. Any attempt to define a default or one-size-
>    fits-all transition scenario, will simply not work. This document
>    does not try to depict the drivers for adoption of IPv6 by an
>    Enterprise.

OK, so the next paragraph shouldn't mention drivers = motivations:

>    While it is difficult to quantify all the potential motivations for

s/motivations/scenarios

>    enterprise network teams to move to IPv6, there are some cases where
>    an abstract description is possible.  The document presents three
>    example motivations as a general use case.   This model can be used to

s/motivations/base scenarios 

>    define additional abstractions, for the Enterprise to define
>    scenarios to fit their requirements.

s/scenarios/specific scenarios

>    The first scenario assumes the Enterprise decides to deploy IPv6 in
>    parallel with IPv4.  The second scenario assumes the Enterprise
>    decides to deploy IPv6 because of a specific set of applications the
>    Enterprise wants to use over an IPv6 network.  The third scenario
>    assumes an Enterprise is building a new network or re-structuring an
>    existing network and decides to deploy IPv6.  The document then
>    defines a set of characteristics that must be analyzed.  The document
>    then provides several scenario examples using the characteristics to

s/several/three specific

>    depict the requirements. These are common Enterprise deployment cases
>    to depict the challenges for the Enterprise to transition a network
>    to IPv6.

I think one "danger" we have here is that by generalising as we do later down
the text, that the requirements become so generalised that the analysis can
apply any mechanism to any scenario :)    I'm not sure whether that is
a real (or important) concern.

>    The interoperation with legacy functions within the Enterprise will
>    be required for all transition except possibly by a new network that
>    will be IPv6 from inception.  The network infrastructure components

Well, not maybe for scenario 2 below, because we are adding IPv6 for a
specific application (let's say a specific IPv6 p2p app like Napster6 :)
and in that case we don't care to access legacy networks, as we are purely
interested in the v6 app, as the scenario states.

>    will inform the Enterprise of key points of transition in their
>    networks that require consideration for IPv6 deployment and
>    transition.

I think "point of transition" is ambiguous - so see below we should define
what you mean.
 
>    Using the scenarios, characteristics, and examples in the document an
>    Enterprise can define a scenario. Understanding the legacy functions
>    and network infrastructure components required, the Enterprise can
>    determine the network operations required to deploy IPv6. The tools
 
The wording is confusing here:  "using a scenario to define a scenario", so
we need to write something else... do we mean:

     Using the base scenarios, characteristics, and examples in the document 
     an Enterprise can define its specific scenario requirements.

>    Enterprise Network    - An Enterprise Network is a network that has
>                            multiple links, a router connection to a
>                            Provider, and is actively managed by a
>                            network operations entity.

s/multiple/multiple internal

s/a router connection/one or more router connections
s/a Provider/one or more Providers
(since you mention multihoming in characteristics below)

Should we define "point of transition" and "characteristic"?  I think it
would help.  Still a nice short set of definitions :)  

>    Three base scenarios are defined to capture the essential abstraction
>    set for the Enterprise. Each scenario has assumptions and
>    requirements. This is not an exhaustive set of scenarios, but a base
>    set of general cases.

We might add another base scenario in Minneapolis but we must ensure that
any such addition really adds value so we keep the doc as simple as possible.
 
> 3.1  Base Scenarios Defined
> 
>    Scenario 1: Enterprise with an existing IPv4 network wants to deploy
>                IPv6 in parallel with their IPv4 network.
> 
> **Note To V6ops WG: Would a network topology map be useful here?

I don't think such a map is necessary for any of the base scenarios.
 
However, by "in parallel" do you mean dual-stack infrastructure or separate 
infrastructure, or is that irrelevant?

>      Assumptions: The IPv4 characteristics have an equivalent in
>                   IPv6.

Where might they not do?
 
>      Requirements: Don't break IPv4 network characteristics
>                    assumptions with IPv6. IPv6 should be equivalent or
>                    "better" than the ones in IPv4, however, it is
>                    understood that IPv6 is not required to solve every
>                    single problem.

Maybe this could say "that IPv6 functionality may not be required, or
feasible to deploy, on all parts of the Enterprise's infrastructure" ?

>     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.
>
>      Assumptions: IPv6 software/hardware components for the application
>                   are available.

Hmmm.  If the reason is to deploy an IPv6 application (e.g. p2p VoIP) the
solution will depend on whether the host is dual-stack (IPv4/IPv6) or 
IPv6(-only).   Clarify, or does it not matter?

>      Requirements: Don't break IPv4 network operations.

That's always a requirement :)   For "operations" read "functionality,
operation or security" maybe, and probably more beyond.

>    Scenario 3: Enterprise deploying a new network or re-structuring an
>                existing network, decides IPv6 is the basis for network
>                communication.

Does this mean IPv6-only network infrastructure?   Remember you have defined
IPv6 above as equal to IPv6-only, so is that what you mean here?
 
>      Assumptions: Required IPv6 network components are available, or
>                   available over some defined timeline.

Again, do you really mean IPv6-only, or IPv6-capable?

>      Requirements: Interoperation and Coexistence with IPv4 network
>                    operations and applications are required for
>                    communications.

So is scenario 3 an IPv6-only network into which IPv6-only or dual-stack
hosts may be deployed?  If so maybe state that 3 paragraphs up.
 
I think the four sets of characteristics below are fine to cover the basic
requirements.

>    Characteristic 1 - Providers for External Network Operation
>    - IPv4 existing address ownership (Provider based addresses vs.
>      Provider independent addresses)?

And number of globally routable IPv4 addresses available?

>    - Do ISPs offer IPv6 service?

By service do you mean native service, or tunnelled, or any service...?

>    Characteristic 3 - Enterprise IT Department Operations Analysis
>    - Is inter-site communications required?

You have "one site vs multiple sites" in characteristic 1?

>    - External IPv4 routing protocols used?

That one belongs in characteristic 1?

>    - List of "network operation" software that may be impacted by IPv6?
>      - DNS
>      - Management (SNMP & ad-hoc tools)
>      - Enterprise Network Servers
>      - Mail Servers
>      - High Availability Software for Nodes
>      - Directory Services

       - Other services (NTP, others...?)

>    - Are all these software functions upgradeable to IPv6?
>    - If not upgradeable, then what are the workarounds?

     - If not upgradeable, can an equivalent upgradeable software function 
       be substituted for the one that is not upgradeable? (e.g. a different
       directory service mechanism)

>    Characteristics 4 - Enterprise Network Management System
>    - Management of Transition Tools and Mechanisms?

This is an important area the WG needs to take on board.

>    - What new considerations does IPv6 create for Network
>      Management?

Does this affect the transition tool analysis, e.g. if RFC3041 means that
IP-based authentication is no longer possible?  I guess it may affect a 
specific implementation of a security policy?

>    This section presents a set of Base Scenario Examples and is not an
>    exhaustive list of examples.  These examples were selected to provide
>    further clarity of Base Scenarios within an Enterprise of a less
>    abstract nature.

I think these are now Specific Scenario Examples not Base ones?  The
answering of the characteristics against the base scenarios higher up
in the document leads to these specific examples?
 
>    A bank running a large ATM network supporting an order of magnitude
>    number of transactions per second, with access to a central database
>    on an external network from the ATM network:

"An order of magnitude number of transactions" is missing a word or two :)
 
>    - External connectivity not required.
>    - Multiple sites connected by VPN.
>    - Multiple sites connected by Native IP protocol.

Perhaps add that it may use Net10 addressing?   We should not hide from the
Net10/ANT issues for transitioning networks.  We have the Hinden draft
on the way, although this example probably uses RFC1918 but not NAT :)
 
> 4.  Support for Legacy IPv4 Nodes and Applications

s/Nodes/Nodes, Services   ?
 
>    The Enterprise network will have to support the coexistence of IPv6
>    and IPv4, to support legacy IPv4 applications and nodes. The
>    Enterprise user has the following choices for that coexistence to
>    consider today.

Does this mean "of IPv6-only and IPv4-only"?  This is what is implied by
the definition of terms at the start of the document.  Do we actually mean
"IPv6-capable and IPv4-capable" or, in the language of the definitions, 
"IPv6, IPv4 and IPv4/IPv6" applications and nodes?

> 4.3  IPv6 communicating with IPv4
> 
>    An IPv6 only node wants to communicate with an IPv4 only node.

Note the node can be IPv4/IPv6 but the application may be IPv4, e.g. if
the source code is lost or the language it is written in has no IPv6 API?

So do we actually mean "node" or "application"?   We probably mean "services
or applications on a node" as RPC, NIS, SMTP etc are services.

>    In cases where the IPv6 host cannot be a dual stack, in order to
>    continue support of communications with IPv4 nodes an IPv4/v6
>    translator is required.  Introduction of such translator will prevent
>    usage of end-to-end security and application carrying embedded IP
>    addressing information.

You could say the translator may be at the network, transport or application
layer.
 
>    **Note to V6ops WG: Should we discuss porting of applications too in
>    the legacy section?

I think this is done in the "application aspects" draft fine already, i.e.
in draft-shin-v6ops-application-transition-01.
 
> 5.  Network Infrastructure Requirements
> 
>    The Enterprise will need to determine what network infrastructure
>    components require enhancements or to be added for deployment of
>    IPv6. This infrastructure will need to be analyzed and understood as
>    a critical resource to manage.
> 
> 5.1  DNS
> 
>    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.
> 
>    **Note to V6ops WG: Should we get into other DNS issues?

There are three categories of issues I think, i.e.

  - standards: dns resolver discovery, 512-byte response format, 
    reverse zone managemnt and dynamic dns

  - transport: root servsers, OS supporting native lookup, and whether the
    upstream ISPs filter the root space /48's

  - registry: registering domains with IPv6 DNS servers

Also, do you have control over your own DNS?

And is it important that reverse DNS lookup works, e.g. for sendmail to
verify sender hosts?  If so reverse population of statelessly autoconfiguring
will be needed, and 6to4 use will be problematic?
 
> 5.2  Routing
> 
>    IPv6/IPv4 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.
> 
>    **Note to V6ops WG: Above is example of additional text we could add
>    to each component we list here.  Are there other Routing issues?

Other issues are whether the upstream provider supports IPv6 natively or
offers transition aids, e.g. 6to4, site tunnel broker.
 
> 5.3  Autoconfiguration
> 
>    IPv6 introduces the concept of stateless autoconfiguration in
>    addition to statefull autoconfiguration.  The enterprise will have to
>    determine the best method of autoconfiguration, for their network.
> 
>    **Note to V6ops WG: Should we get into other autoconfiguration
>    issues?

Will the enterprise need IPv6 prefix delegation?

Will it need DHCPv6 forwarding?
 
> 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.
> 
>    **Note to V6ops WG: Should we get into other security issues?

I think Pekka's security draft could be cited:
draft-savola-v6ops-security-overview-00

Issues include backdoors for tunnels, handling firewall policy for end-to-end
encryption, dual-stack possibly adding complexity to analysis, and DoS relay
type attacks (e.g. 6to4 relays).

> 5.5  Applications
> 
>    Existing applications will need to be ported to support both IPv4 and
>    IPv6.
> 
>    **Note to V6ops WG: Should we get into other application issues?

Not beyond the shin-v6ops draft.
 
> 5.6  Network Management
> 
>    The addition of IPv6 and points of transition will need to be managed
>    by the Enterprise network operations center.  This will affect many
>    components of the network and software required on nodes.
> 
>    **Note to V6ops WG: Should we get into other Management issues?

Probably not.
 
> 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.
> 
>    **Note to V6ops WG: Should we get into other Address Planning issues?

Would IPv4 and IPv6 subnets be congruent?

An advantage of IPv6 is that you are unlikely to ever need to resize the
subnets (up or down).

Available IPv4 address space affects (for example) the DSTM pool, NAT-PT, etc.

Do we have address space independence from provider?
 
>    **Note to V6ops WG: What other components are we missing?

Here are some additional possible components:

5.8  Multicast

Both from routing aspects, but also things like MLDv1/2 snooping to help
avoid traffic flooding.

If multicast is needed then some tools may not be useful, e.g. 6to4 (there
was a draft on 6to4 and multicast, but it seemed to have died).

5.9  Service discovery mechanisms

The infrastructure may need to support many of these because there is little
harmonisation of techniques in various standards, e.g.
 - LDAP or NIS
 - Well-known names
 - Well-known addresses
 - IPv4 or IPv6 anycast
 - LLMNR
 - DHCPv6 (Lite)
 - SLP, etc

> 7.  References

Maybe the applications draft (see above) and Pekka's transition 
architectures doc?  (draft-savola-v6ops-transarch-01)  And his security
doc: draft-savola-v6ops-security-overview-00 ?

There's also RFC1752 which we could either cite or state that we no 
longer use as a yardstick.   It talked about transition goals like:
  - incremental upgrade (hosts not routers)
  - incremental deployment (routers)
  - easy addressing (use dual-stack)
  - low start-up costs (procure wisely so infra enabled)

Other general comments:
-----------------------

What about preference of use of IPv4 or IPv6?

How do we handle the "NAT is our policy" sites?

Are IPv6-specific features out of scope... e.g. privacy extensions which
may impact policy implementations like (weak) IP-based authentication?

What about remote IPv4 nodes wishing to access your site IPv6(-only) services?
Do you deploy (say) NAT-PT yourself, or rely on the remote site to introduce 
its own tools?   Maybe this is covered OK in 4.3, but we could explicitly
expand on it.

What about use of existing "software functions" that may ease transition,
e.g. if already using proxies like web, mail, etc already, or using VLANs?

We should capture general transition tool requirements somewhere, e.g. a site
depends on handling 100,000 remote transactions per hour, then any proxies,
translators, etc must be able to support that level.   

Tim

---

From: Pekka Savola <[email-masked]>
Date: Mon, 20 Oct 2003 09:48:57 +0300 (EEST)

> comments is mainly for clarification :)
[...]

Thanks Tim.  These kind of comments are exactly what we need to move the
scenarios documents forward.  Hopefully other folks also have a chance to
read and comment on the document.

Pekka
 writing as WG co-chair

---

From: "Eva M. Castro" <[email-masked]>
Date: Tue, 21 Oct 2003 14:57:44 +0200

Hi,

First, thanks for this draft, I think it is very useful to analyze
and understand transition aspects. Im also agree with the idea that
defining a default transition scenario, will not work. However,
this draft helps to think about key aspects when moving to IPv6.

Some comments around this draft:

--> In table of contents:

"
3.  Base Scenarios..............................................6
3.1  Base Scenarios Defined.....................................6
3.2  Scenarios Characteristics..................................6
3.3  Base Scenario Examples.....................................8
"

I understand point 3.1 and 3.3 are very different, point 3.1 explains
transition scenarios, or IPv6 scenarios, and point 3.3 explains
existing enterprise scenarios. Maybe, it is more clear if the name
of these subsections is changed:
 
3.1 IPv6 transition base scenarios.
3.2 Scenarios Characteristics.
3.3 Enterprise specific scenario examples.

>infrastructure, or is that irrelevant?

--> If it was not dual-stack infrastructure, I think it would be
scenario 3. If this scenario is related to dual-stack, maybe it could
be named dual-network.

>>     Assumptions: The IPv4 characteristics have an equivalent in
--> Maybe scenario 2, only some specific IPv6 applications should work,
so not all IPv4 services are required in the IPv6 network.

>IPv6 above as equal to IPv6-only, so is that what you mean here?
--> I suppose this scenario is an IPv4 and IPv6 heterogeneous network which
will converge to an IPv6 network, where an IPv4 and IPv6 heterogeneous
network is a set of network zones, IPv4-only, IPv6-only and dual stack.

>Again, do you really mean IPv6-only, or IPv6-capable?
--> I understand every kind of node, without loosing  IPv4/IPv6
interoperability. Not sure if it is required to emphasize the different
kind of nodes in this scope.

>hosts may be deployed?  If so maybe state that 3 paragraphs up.
--> I thought scenario 3 was an IPv4 and IPv6 heterogeneous network, since
dual-stack network was scenario 1.

>And number of globally routable IPv4 addresses available?
--> Very important for some transition mechanisms which require a
pool of routable IPv4 addresses.

>"IPv6, IPv4 and IPv4/IPv6" applications and nodes?
--> In my opinion, coexistence means interoperability between every kind
of node and application that enterprise requires. Again, not sure if the
different kind of nodes and applications should be distinguished in this
scope.

--> Section 4 is named "Support for Legacy IPv4 Nodes and Applications"
however applications are not mentioned in this section. So, maybe it should
be named "Support for Legacy IPv4 Nodes".

--> maybe  4.1 and 4.2 cases could be more general if they are 
considered as:

4.1. Communicating IPv4 networks through IPv6 zone
4.2. Communicating IPv6 networks through IPv4 zone.

These two cases include that end-point nodes are dual stack or single stack
and tunnels can be started from end-point nodes (dual stack) or from
intermediate router (end point nodes are single stack). Besides, I think
it is more coherent with the name of the subsection 4.3, "IPv6 
communication
with IPv4" which is about connecting networks, not nodes.

Regards,

eva

-- 
Eva M. Castro <[email-masked]>

---

From: Tim Chown <[email-masked]>
Date: Tue, 21 Oct 2003 14:04:46 +0100

> 3.3 Enterprise specific scenario examples.

I guess my comments were too long for you - I suggested the same :)
 
There was some confusion between motivations, scenarios, base scenarios
which I suggested some changes for.  Jim will be back in a week or so
and I'm sure will start collating comments.   So some reinforcement in
suggestions is good.

> kind of nodes in this scope.

So this is a terminology issue.  In the definitions section, IPv6 is
defined as IPv6-only.  Then in the text "IPv6" is used freely and may
mean either IPv6 in general or IPv6-only.  Maybe we should explicitly
write IPv6-only when we really mean it, to avoid any possible confusion.
 
> different kind of nodes and applications should be distinguished in this

Agree - the interworking is between nodes and applications; not all apps
will be capable of both protocols, some will be IPv6-only, like new p2p
apps for v6 - these may never talk to v4 except by proxies.
 
Tim

---

From: "Eva M. Castro" <[email-masked]>
Date: Wed, 22 Oct 2003 09:22:08 +0200

>I guess my comments were too long for you - I suggested the same :)
ups! sorry :)

>and I'm sure will start collating comments.   So some reinforcement in

--> Agree with you and Chirayu.

Maybe, think of  steps to get IPv6 in the enterprise scenario and 
try to connect  aims of enterprise, network characteristics and final
scenario:
1) Think of applications will be run in the enterprise network.
2) Select the enterprise scenario based on the applications.
3) Get existing enterprise network characteristics.
4) Ways to obtain the enterprise scenario.

Chirayu Patel wrote:
 >2. The scenario description in section 3.1, and the examples in section

>   3.3 do not seem to be in tune. The purpose of section 3.3 is to
>   provide clarity on the base scenarios but, IMHO, it does not do that.
>   For example, how does the example network A shed more light on
>   Scenario 1, or 2, or 3?

Regards,

eva