Subject: RE: I-D ACTION:draft-baker-v6ops-end2end-00.txt

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Aug 2005 09:48:00 -0700

Hello Fred,

I enjoyed reading this informative draft and agree for the
most part with its conclusions. I have one doubt about
section 2.1, step 5. where it says:

>   5.  At some point in the (very) distant future, IPv6 connectivity is
>       sufficiently ubiquitous that IPv4 connectivity becomes
>       unnecessary.  At this point, businesses independently remove
IPv4
>       from the network as being no longer useful."

If and when we reach such a point in the (very) distant future, it
seems safe to say that *applications* would cease to use IPv4 but I
wonder if we can safely predict that businesses would remove IPv4 from
their *networks*? I.e., it seems conceivable that IPv4 might remain
in networks for some time (perhaps even indefinitely) after
applications cease to use IPv4. 

Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, August 15, 2005 12:50 PM
> To: [email-masked]
> Subject: I-D ACTION:draft-baker-v6ops-end2end-00.txt 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> 
> 
>      Title        : The End to End Problem in a fully generalized
>                            IPv4, IPv6, and IPv4+IPv6 network
>      Author(s)    : F. Baker
>      Filename    : draft-baker-v6ops-end2end-00.txt
>      Pages        : 23
>      Date        : 2005-8-15
> 
>     This note is intended to describe the end to end problem as it
>     applies to a network of networks, wherein some component networks
>     independently run only IPv4 with or without a transition 
> mechanism,
>     some run only IPv6 with or without a transition mechanism and  
> without
>     coordination of transition mechanisms, and some run IPv4 
> and IPv6 in
>     parallel supporting native routing.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-baker-v6ops-end2end-00.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-baker-v6ops-end2end-00.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-baker-v6ops-end2end-00.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.
> --------------------------------------------------------------
> ---------- 
> -
> 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: j7FK4TVS011545
> 
> 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
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 
>

---

From: Fred Baker <[email-masked]>
Date: Tue, 16 Aug 2005 10:03:58 -0700

The word "very" is operative in that sentence. That said, yes, of  
none of the applications are using IPv4, there is an ongoing cost to  
maintaining it (if nothing else, training, testing, and configuration  
maintenance), and at some point one must presume that someone will  
wonder why he's paying the cost. We have people asking that question  
already, which is the impetus behind the discussion of IPv6-only and  
IPv6-dominant networks.