Subject: I-D ACTION:draft-ietf-v6ops-ent-analysis-02.txt

From: [email-masked]
Date: Thu, 19 May 2005 15:45:42 -0400

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 Analysis
	Author(s)	: J. Bound, et al.
	Filename	: draft-ietf-v6ops-ent-analysis-02.txt
	Pages		: 33
	Date		: 2005-5-19
	
This document analyzes the transition to IPv6 in enterprise
 networks.  These networks are characterized as a network that has
 multiple internal links, one or more router connections, to one or
 more Providers, and is managed by a network operations entity.  The
 analysis will focus on a base set of transition notational networks
 and requirements expanded from a previous Enterprise Scenarios
 document. Discussion is provided on a focused set of transition
 analysis required for the enterprise to transition to IPv6,
 assuming a Dual-IP layer (IPv4 and IPv6) network and node
 environment, within the enterprise.  Then a set of transition
 mechanisms are recommended for each notational network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-02.txt

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-analysis-02.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-analysis-02.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: Fred Baker <[email-masked]>
Date: Thu, 19 May 2005 15:02:47 -0700

The enterprise analysis draft has been posted for review. Please read  
it and comment to the list. It would be nice to be able to complete  
last call on this before our meeting in August, or to know that there  
are issues we need face time to discuss.

On May 19, 2005, at 12:45 PM, [email-masked] wrote:

> ----------------------------------------------------------------------- 
> --
> CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
> ----------------------------------------------------------------------- 
> --
> In order to maintain computing infrastructure integrity, Cisco Systems
> Enterprise Messaging Services and InfoSec teams have set a mail policy
> disallowing executable attachments in email.
>
> This message contained an executable attachment type that is prohibited
> by this policy. The attachment has been removed from this message and
> copied to quarantine by our systems. It will be held in quarantine for
> seven days in the event that the content needs to be retrieved.
>
> Please be aware many viruses attempt to look like legitimate email or
> notifications from anti-virus systems. We will clearly mark a  
> seperation
> between our notifications and the original email as follows:
>
>   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY"
>
> For further reference information about viruses and email antivirus
> efforts within Cisco, please visit:
>
> http://wwwin.cisco.com/it/ems/services/antiviral
>
> If your concern isn't addressed by the information in this notification
> or the above web page, you may open a support request:
>
> http://wwwin.cisco.com/support/
>
> Select "Messaging", "Email-Related", "Mail Routing"
>
> Please include in the text of your case the following information:
>
> * Full headers of the message. Documentation on displaying the full
> headers is available at this URL:
>
> http://wwwin.cisco.com/support/library/faqs/solution002471.html
>
> * This unique quarantine identifier: j4JJm8re029656
>
> If the matter is urgent, you may follow up by calling one of the below
> referenced numbers. Please make every effort to provide the above
> requested information via the support web tool prior to calling as it
> will greatly aid the resolution of your issue.
>
> Americas:
> 1 408 526 8888
>
> Asiapac
> +61 2 8446 8888
>
> EMEA
> +31 20 485 4888
>
> Japan
> +81 3 5549 6888
>
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
>
> Thank you for your cooperation,
>
> Enterprise Messaging Services
> Cisco Systems, Inc
>
> --OtherAccess--

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 20 May 2005 12:14:27 -0400

Does the WG really have consensus on this recommendation?

  Later in the transition process, after the enterprise has
  transitioned to a predominately IPv6 infrastructure, the architect
  should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or
  in the case of early deployment of IPv6-dominant networks DSTM can
  be used too.

This whole document comes down to a brief set of recommendations, and 
I think that it is important that we only make recommendations that 
have the clear consensus of the WG.

I am not personally convinced that we should recommend DSTM as a 
solution for this stage of network transition (I haven't even read 
DSTM+, so I have no opinion on that), but perhaps I am part of the 
rough?  Fred, was there an explicit consensus call on each of these 
recommendations that I missed while I was busy somewhere else?

If the WG does have consensus that, at some point in an enterprise 
transition, administrators "should implement DSTM", what is our plan 
to standardize it?

Margaret

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 May 2005 10:54:05 -0700

I'm not at all clear that DSTM is being recommended by the working 
group - or any specific transition mechanism. Our charter specifically 
excludes discussion of transition mechanisms, and I note that the IESG 
recently approved Teredo as a Proposed Standard, which I think means 
that the IETF recommends that. And personally, I'm not convinced that 
any of the proposed transition mechanisms are sufficient, as I don't 
see documented anywhere a single transition mechanism simultaneously 
solves all four problems:

  - an IPv4-only system finding and communicating with another IPv4-only 
system across an IPv6-only infrastructure
  - an IPv6-only system finding and communicating with another IPv6-only 
system across an IPv4-only infrastructure
  - an IPv4-only system finding and communicating with an IPv6-only 
system
  - an IPv6-only system finding and communicating with an IPv4-only 
system

My history with this document and with the DSTM proposal is that I took 
over the WG last March. In the WG meeting in march, DSTM was not 
discussed, and the discussion of the enterprise analysis identified a 
number of items to be corrected. We have just gotten the updated 
document, and it needs thorough review.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 May 2005 16:58:49 +0200

Margaret,

>  in the case of early deployment of IPv6-dominant networks DSTM can

Could we agree on s/should implement/should consider implementing/?

    Brian

---

From: Eric Vyncke <[email-masked]>
Date: Tue, 31 May 2005 17:44:48 +0200

Just a couple of minor issues:

4.2.1) about IPv6 routing capability, it may be wise to state the obvious: IPv6 routing capability should offer the same performance as the existing IPv4 routing in order to handle the peak load requested by dual stack hosts.
Moreover, the IPv6 routing node should execute the same features as the IPv4 routing node: QoS, security, availability (redundant links for IPv6 when there are redundant links for IPv4) ...

5.1) the external IPv6 tunneling also presents security & QoS issues that should probably be mentioned

The last point is linked to 4.2.1, when the IPv6 connectivity is poor: like route flapping, link flapping (spec. with tunnels), IPv6 isolated islands will be created and this will cause some applications to fail since they will insist in using IPv6 address (even if both ends are still using IPv4). On my own experience, this was really a pain in ... to detect this issue.

Hope it helps

-eric