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

[Tim Chown <tjc@ecs.soton.ac.uk>]

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