Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt

From: Tim Chown <[email-masked]>
Date: Fri, 2 Jul 2004 01:26:10 +0100

Hi Jim,

It looks good to go.

Very minor comment (can be ignored if we want to get the draft published :)

Perhaps Section 3.1 could be clearer - is the correct interpretation:

Scenario 1:  Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable
hosts and network infrastructure.

Scenario 2:  Sparse IPv6 dual-stack deployment in IPv4 network infrastructure.

Scenario 3:  IPv6-only network infrastructure with some IPv4-capable 
nodes/applications needing to communicate over the IPv6 infrastructure.

If so, then 

"   Scenario 3: Enterprise deploying a new network or re-structuring an
               existing network, decides IPv6 is the basis for
               most network communication, to coexist with IPv4."

might be better as:

"   Scenario 3: Enterprise deploying a new network or re-structuring an
               existing network, decides IPv6 is the basis for most network 
               communication.  Some IPv4 capable nodes/applications will
		need to communicate over that infrastructure.

Or is that the wrong intepretation?

Finally, how does communication between IPv4-only and IPv6-only nodes or
applications fit into the above three scenarios, if any of them?  Would
that be part of Scenario 3?  Perhaps make that clearer?

Section 3.1 is actually quite heavily the key in which mechanisms are
favoured, so the wording is very important.

Tim

On Tue, Jun 29, 2004 at 12:30:26AM -0400, Bound, Jim wrote:
> WG,
> 
> Chairs asked me to send this note to you. Updated spec below. First
> error below I am just the editor see authors in the spec.  What we did
> and I as editor is took 100% Alain's and Pekka's input as best we could
> for additional clarity.  But, in section 4 we put additional note that
> this section is more of an overview that the reader must look at as
> components and all the components would fill up many pages (as all
> scenarios) and more of that is analysis as opposed to defining a
> scenario, and analysis is the next step.  We also added normative
> references we felt were applicable to the spec that exist and talk about
> the general subject (e.g. DNS, Applications).  I as one author may not
> be able to respond to mail this week as I am abroad in Europe, but will
> do my best.  
> 
> Regards,
> /jim
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Monday, June 28, 2004 3:31 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 Operations Working Group of the
> IETF.
> 
> 	Title		: IPv6 Enterprise Network Scenarios
> 	Author(s)	: J. Bound
> 	Filename	: draft-ietf-v6ops-ent-scenarios-03.txt
> 	Pages		: 16
> 	Date		: 2004-6-28
> 	
> This document describes the scenarios for IPv6 deployment within
> Enterprise networks.  It will focus upon an Enterprise set of network
> base scenarios with assumptions, coexistence with legacy IPv4 nodes,
> networks, and applications, and network infrastructure requirements.
> These requirements will be used to provide analysis to determine a set
> of Enterprise solutions in a later document.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-03.tx
> t
> 
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-v6ops-ent-scenarios-03.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-03.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 2 Jul 2004 10:14:50 -0400

Hi Tim,

>that be part of Scenario 3?  Perhaps make that clearer?

Can you describe a situation where this is necessary?

My preferred "solution" to this problem is to avoid the situation.  Nodes
that  need to speak to IPv4-only nodes must implement IPv4, and nodes
that need to speak to IPv6-only nodes must implement IPv6.  Nodes
that need to talk to both IPv4-only and IPv6-only nodes must be dual
stack.  An IPv4-only  node would not be able to communicate directly
with an IPv6-only node.

In this situation, the question changes from "How does an IPv4-only
node talk to  an IPv6-only node?" to "How do we get IPv6 connectivity
to a node that only has local IPv4 connectivity, and vice versa?".

So far, I haven't heard of any situation where IPv4<=>IPv6 translation
would be technically superior to dual stack/tunneling.

Margaret

---

From: Tim Chown <[email-masked]>
Date: Sun, 4 Jul 2004 17:06:12 +0100

> stack.  An IPv4-only  node would not be able to communicate directly

This is the IETF mantra, and I agree with it.  The question is how reasonable
will it be?   In some places, in order to run dual-stack it'll have to be
IPv4 private addressing and IPv6 public addressing together.   Perhaps some
(mainly greenfield) networks will just decide IPv4 isn't worth deploying
and will offer translation (probably ALGs) for legacy applications like mail, 
web and FTP and rely on IPv6 for all new or intranet applications?   Do
you think this would be unreasonable, especially in less well IPv4-endowed
areas?
 
There are actually many academic sites that rely on ALGs, e.g. student
dormitory networks, which might only have web ports open outbound, and
use private IPv4 addressing.  These could be candidates for IPv6 deployment
experiments, although in many cases the restriction is of course not because
of IPv4 address shortage, but policy decisions.

Tim