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

From: "Bound, Jim" <[email-masked]>
Date: Sun, 19 Oct 2003 21:11:02 -0400

Tim,

Thanks for your review.  I am on R&R this week so cannot respond.  Also
the document when announced should have said Jim Bound (EDITOR).  I will
hope that my other team members can comment and begin this discussion
with you.  Wherever you have "you" below though, WG should replace with
"design team" in their mind.  So its not "my" view or "my" doc or
whatever.  Point is this is great to see and it would be good of if the
WG could have good discussion on this mail list.  Though Tim you are on
the Enterprise Design team and you know we had a deadline to make the
-00 and we would have loved to have received this input off line before
ID submission date, but good you found time to review quickly.  You
should answer your own questions here too as member of the team :--)

I will keep all of these responses and answers as Editor and record.  If
I have input from study of the responses, I will assemble as few
responses as possible from my view to support the chairs wanting to keep
email well thought out and constructive and reduced.  Tim's mail IMO is
a good example of that case too. After R&R time-out this week of course.

thanks
/jim

> -----Original Message-----
> From: Tim Chown [mailto:[email-masked]] 
> Sent: Saturday, October 18, 2003 7:59 AM
> To: [email-masked]
> Subject: Comments on draft-ietf-v6ops-ent-scenarios-00
> 
> 
> 
> 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: "Chirayu Patel" <[email-masked]>
Date: Tue, 21 Oct 2003 11:25:40 +0530

Some quick comments:

1. The definition of scenario needs to be clarified. I was under the
   assumption that a scenario would correspond to a stage in the
   deployment of IPv6 in the enterprise network. For example,
   the cases described in section 5 in
   http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-
   scenarios-03.txt.

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?

CP

On Mon, 20 Oct 2003 09:48:57 +0300 (EEST), "Pekka Savola"
<[email-masked]> said:
> On Sat, 18 Oct 2003, Tim Chown wrote:
> > 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 :)
> [...]
>
> 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: "Bound, Jim" <[email-masked]>
Date: Wed, 22 Oct 2003 21:41:43 -0400

CP,

Thanks for the comments.

> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-sce
narios-03.txt.

The Enterprise Scenarios are exponentially greater than uman scenarios.
Thus the potential stages of deployment within those is even greater.
What we could do is add a stages of deployment section to try to provide
a reference for users to be aware of to take those into consideration.
But Enterprises are quite different and will approach this in many
different ways.

Fair question.  We need to provide that in an appendix.  All three
examples 3.1 could apply to all specific examples in 3.3.  And we need
to cover this in the spec and then show examples in the spec.

For example:

Example Network A:

   A distributed network across a number of geographically separated
   campuses

Each scenario in 3.0 could be applied to Network A.

Then:
  - External network operation.
   - External connectivity required.
   - Multiple sites connected by leased lines.
   - Provider independent IPv4 addresses.
   - ISP does not offer IPv6 service.
   - Private Leased Lines no Service Provider Used

Each apply for this example from each scenario.

   Applications run by the enterprise:
   - Internal Web/Mail.
   - File servers.
   - Java applications.
   - Collaborative development tools.
   - Enterprise Resource Applications.
   - Multimedia Applications.
   - Financial Enterprise Applications.
   - Data Warehousing Applications.

These could be required in all 3.0 scenarios.

   Internal network operation:
   - In house operation of the network.
   - DHCP (v4) is used for all desktops, servers use static address
     configuration.
   - The DHCP server to update naming records for dynamic desktops uses
     dynamic DNS.
   - A web based tool is used to enter name to address mappings for
     statically addressed servers.
   - Network management is done using SNMP.
   - All routers and switches are upgradeable to IPv6.
   - Existing firewalls can be upgraded to support IPv6 rules.
   - Load balancers do not support IPv6, upgrade path unclear.
   - Peer-2-Peer Application and Security supported.

This could be the case for each scenario too.

The idea is 3.0 scenarios state generic base solutions that cover a wide
range of Enterprise approaches to IPv6 deployment.

Then 3.3 "specific examples" give types of networks that could use any
of the base scenarios.

/jim

CP

On Mon, 20 Oct 2003 09:48:57 +0300 (EEST), "Pekka Savola"
<[email-masked]> said:
> > 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.
> >

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 22 Oct 2003 21:41:43 -0400

Hi Eva,

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

Thanks we appreciate the comment and support.

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

Yes this is similar to Tim's input.  Agreed.

> Tim Chown wrote:
> >However, by "in parallel" do you mean dual-stack infrastructure or 
> >separate
> --> 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.

Hmmm.  Might be good idea.  Good point.  We need to think about that.

> --> Maybe scenario 2, only some specific IPv6 applications 
> should work,
> so not all IPv4 services are required in the IPv6 network.

Yes we need to fix this set of statements.

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

Yep.  The tricky part here is what does IPv6 only mean and imply and do
we go there in the spec?

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

Thats why if we can leave it as IPv6 capable for the draft it will let
us evolve to the real work.

> paragraphs 
> >up.
> --> I thought scenario 3 was an IPv4 and IPv6 heterogeneous network, 
> --> since
> dual-stack network was scenario 1.

It is but we can make this more clear or I as Editor.

> --> Very important for some transition mechanisms which require a
> pool of routable IPv4 addresses.

Agreed.  This will get added.

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

I hope that differentiation is not required and agree with you.

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

Interesting point.  Need to think.

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

Yep.

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

Good input and words for us too.  Thanks.

Thanks
/jim

> 
> Regards,
> 
> eva
> 
> -- 
> Eva M. Castro <[email-masked]>
> 
> 
> 
> 
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 22 Oct 2003 21:41:43 -0400

Note to WG and the counter for mail messages.  I am going to be
responding to lots of mail as Editor for Enterprise Scenarios.  I will
do my best to keep my opinions and diatribe out of this mail but need to
acknowledge the responses.  I will be as Terminator 1 and mission is to
get edits right and verify corrections or ask for clarification.  So I
may appear on the counter next week or the next few.  But as Editor.
Other inputs I try to keep to no more than 10 mails a week.  /jim

> Sent: Tuesday, October 21, 2003 9:05 AM
> To: [email-masked]
> Subject: Re: Comments on draft-ietf-v6ops-ent-scenarios-00
> 
> 
> On Tue, Oct 21, 2003 at 02:57:44PM +0200, Eva M. Castro wrote:
> > 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:
> > 
> 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.

I am not back really, I just love you people so much I had to jump back
to cyberspace :--).  I will try to fix this confusion as Editor ok.  But
need to think and send short message to the WG to state a suggestion of
text for direction for the spec.  See if all can support it ok.  Thanks.

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

Same response as above.

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

Thanks
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 22 Oct 2003 21:41:43 -0400

CP,

Thanks for the comments.

narios-03.txt.

For example:

Example Network A:

Then:

/jim

CP

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 22 Oct 2003 21:41:43 -0400

CP,

Thanks for the comments.

narios-03.txt.

For example:

Example Network A:

Then:

/jim

CP

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 22 Oct 2003 21:41:43 -0400

Same response as above.

Thanks
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 22 Oct 2003 21:41:41 -0400

Hi Tim,

Thanks for your hard work and thorough read of the specs and good input
to the work.

> ideal but I hope they are still useful prior to Minneapolis.

Very useful.

> The detail of comments is mainly for clarification :)

The team thanks you for that comment.

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

Thanks.

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

Good catch.

> >    While it is difficult to quantify all the potential 

yep.

> s/motivations/base scenarios 

yep.

> s/scenarios/specific scenarios

excellent.

Yep.

> a real (or important) concern.

I think it is an important concern and the hope is we fine tune the
generalizations to be specific enough to keep a focused effort for the
analysis.  

> app, as the scenario states.

This is good point about secenario 2 and good catch.

> should define what you mean.

Agreed in next release we will remove all references of "point of
transition" it is here now to get folks to think points of transition
and now its time to define them I personally agree with you.

>      an Enterprise can define its specific scenario requirements.

Yes much better.

> s/multiple/multiple internal

Yes.

> (since you mention multihoming in characteristics below)

Yes.

> I think it would help.  Still a nice short set of definitions :)  

I think point of trasition for a spec is going give us trouble but I do
think defining characteristic is good idea.

> the doc as simple as possible.

This has 100% consensus by the team.  I agree.

> I don't think such a map is necessary for any of the base scenarios.

Thanks for that input.

> infrastructure, or is that irrelevant?

I think we need to explain what we mean in next release.  But some nodes
will be dual stack and some nodes will be IPv4.  I don't think to many
will be IPv6 only.

> >      Assumptions: The IPv4 characteristics have an equivalent in

I just wrote this one down as it came from last input.  I think we need
to discuss what this means as a team and be great if our WG colleagues
would jump in on this specific too.  I think it is vague and unclear.
IPv6 will have functions that do not exist in IPv4 as one example.

> Enterprise's infrastructure" ?

Yes I like this much better.  Note again I just copied this from input.
So we may have to have some discussion but I support your suggestion.

> IPv6(-only).   Clarify, or does it not matter?

Well I cheated and admit it to all :---).  Bringing IPv6 only into this
complicates the discussion and eventual consensus for this work.  I
think in this case it does not matter in the node instance and the
network instance if the IPv6 packet is delivered.  But, what it affects
is the transition mechanisms required if the node is IPv6 ONLY to speak
with legacy IPv6 nodes.  That is the one area where translation is
required.  

But does IPv6 only mean that the node simply does not have an IPv4 stack
at all.  I don't see that happening for a long time.  I suggest we
assume dual stack for this work and not IPv6 only.  That for IPv6 ONLY a
future addendum to this spec be written?

What does the WG think about my suggestion above?  Thanks.

> operation or security" maybe, and probably more beyond.

Yep.  But it was felt it needed to be said in the spec.

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

IPv6 Capable. I need to fix that above ok.

> dual-stack hosts may be deployed?  If so maybe state that 3 

IPv6 capable but will fix that above too.  I want to start another
specific thread on this for the WG to discuss to from your input.  Good
catch.

> cover the basic requirements.

Thanks.

> And number of globally routable IPv4 addresses available?

Yes.

> By service do you mean native service, or tunnelled, or any 

Any.  But we should differentiate the two as it relates to what the
Enterprise can do.

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

Will fix I figured providers as plural implied "multiple". 

> That one belongs in characteristic 1?

Yes.

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

Lets add to the list but at some point we need to add at the end "etc..
etc..".

>        directory service mechanism)

This I think is to be done in the analysis spec??????????
> This is an important area the WG needs to take on board.

Yep.  I think Management Scenarios could be its own spec?

> specific implementation of a security policy?

Yep. But what I was thinking here is what new problems does transition
introduce onto the network of the enterprise?  That list would be useful
I think.  Esp. in Ent Scenarios to feed Ent Analysis doc.

> scenarios higher up in the document leads to these specific examples?

Excellent. I knew this in the head but could not hit my fingers while
editing. Thanks.

> "An order of magnitude number of transactions" is missing a 

Well we don't have data to say numbers.  Nor should we.  We do need to
say this better I was as Editor taking liberty to get the point across
we need better wording yes.  But trying to state hard facts is not good.

> Hinden draft on the way, although this example probably uses 

Yes and was not hiding just missed it as I hate it so bad and needed the
reminder :--)

> s/Nodes/Nodes, Services   ?

Yes.

> "IPv6, IPv4 and IPv4/IPv6" applications and nodes?

I will fix all this in the doc to relay IPv6 capable.

> or applications on a node" as RPC, NIS, SMTP etc are services.

Nope I was bringing out the case of an IPv6 stack only node.  That
should be changed.

> You could say the translator may be at the network, transport 

We can add that but for this "reference" model document I don't think it
matters?

> already, i.e. in draft-shin-v6ops-application-transition-01.

I agree and we can point to this work too.

>   - registry: registering domains with IPv6 DNS servers

Agree but is Enterprise Scenarios the only spec that needs to address
that what about Umanaged, 3GPP, or ISP docs?  

> Also, do you have control over your own DNS?

This is important to state yes.

> statelessly autoconfiguring will be needed, and 6to4 use will 

This is true for all scenario documents, is Enterprise work the only
spec that has to do this or do we need a generic DNS transition document
as Management etc...

> natively or offers transition aids, e.g. 6to4, site tunnel broker.

Yes.

> Will the enterprise need IPv6 prefix delegation?

I think so :--).  But we should add that to the list too.

> Will it need DHCPv6 forwarding?

Do you mean relaying?

> draft-savola-v6ops-security-overview-00

I want to not respond and need to do more in depth read of that spec.  I
think being paranoid is not good :--) (no refelection on Pekka's
security draft I just think we live in a very dangerous world and thats
life. Trying to correct that to far is not worth the time and one is
better off to die :--)).  Just kidding.  I will reread Pekka's work.

> complexity to analysis, and DoS relay type attacks (e.g. 6to4 relays).

Yes for sure.

> Not beyond the shin-v6ops draft.

Agreed.

> >    **Note to V6ops WG: Should we get into other Management issues?

I agree.  But we proabably need a network management draft of its own.

> Would IPv4 and IPv6 subnets be congruent?

I think parallel is more correct?

> resize the subnets (up or down).

ERRRRRRRRRRRRRRRRR.  Need to think about that.  One could blow the bits
to the left on a site boundary with sensors :--).

> Available IPv4 address space affects (for example) the DSTM 

Yes but that has to be in analysis but we should generically point to
all this list.
> Do we have address space independence from provider?

I don't believe this is true at all?  We do not even more so with IPv6
and I don't like that quite frankly ...................

> e.g. 6to4 (there was a draft on 6to4 and multicast, but it 

We should add this yes.

> there is little harmonisation of techniques in various standards, e.g.

Yes.

> doc: draft-savola-v6ops-security-overview-00 ?

Yes. But want to reread Pekka's security overview ok.

>   - low start-up costs (procure wisely so infra enabled)

Good point.  Yes.

> Other general comments:

Ouch. I fear a 1000 mail message debate.  I suggest we avoid this and
leave scenarios for the enterprise to have that debate when they deploy.
OK.

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

We do need to add this as you stated above.  But not get into email war.

> (weak) IP-based authentication?

In the scenarios I think they are but will have to see once we start
analysis.

> its own tools?   Maybe this is covered OK in 4.3, but we 

We should have a reference in scenarios so this can be discussed in
analysis.

> transition, e.g. if already using proxies like web, mail, etc 

Possibly a footnote.  But we should stay within the charter expertise of
this IETF WG.

> translators, etc must be able to support that level.

Maybe for sure in scenarios as long as it does not point to or suggest
any specific mechanism ok.

thanks
/jim