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

From: [email-masked]
Date: Mon, 15 Aug 2005 15:50:01 -0400

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: "Eric Klein" <[email-masked]>
Date: Tue, 16 Aug 2005 19:27:07 +0300

Fred,

A few comments (mostly nits).

1. This is the first time I have seen a draft that refers to it's self as a
note ( in the  abstract and introduction), this seems like the wrong word.

2. In the last sentence of section 2.1 it reads:
   "IPv4, there is at minimum IPv4 connectivity",
I recommend it read:
  "IPv4, there is at a minimum IPv4 connectivity"

3. In the last sentence of section 3 it reads:
  ' "A satisfactory solution", it could be said, "contains no unnecessary
complexity", and "first, does no harm." '

This seems a little confusing, as the one with first is second or last. It
may be confusing for non-native English speakers.

4. In section 3.1, in the third paragraph ("If the central IPv4 networks are
providing the"), is this referring to the backbone or interconnection points
(like the public MAE (east/west) Internet Exchange or any of the hundreds of
private ones)? Are there any drafts that talk about converting the backbones
or interconnection points to IPv6 using any of the methods used (tunnel
broker, etc) or are they all end network based (like Tredeo, etc). If not
then this or another one might help solve some of the problems you are
discussing.

For example MAE (run by MCI http://www.mae.net/svc/mae-ipv6.htm) states:
    IPv6 and IPv6 peering services reside on the same level 2 exchange
switch fabric. IPv6 is
    transparent to  the switching platform and the access type (ATM, Frame,
or GigE), and the
    connections are supported by PeerMaker. Customers may choose to use a
separate port for
    IPv6 or share the same port among IPv6 and IPv4 connections. The service
supports native,
    dual-stack, tunneling connections configurations.

    Important
    IPv6 is not supported for interworked connections between a GigE port
and either a Frame
    or ATM port.

Please note that they support tunneling, but do not say which type (just as
you describe).

Eric

---

From: Fred Baker <[email-masked]>
Date: Tue, 16 Aug 2005 11:31:48 -0700

> note ( in the  abstract and introduction), this seems like the  

Without taking the time to do a full investigation, I note that RFC  
#10 opens with the phrase "This note is a revision of NWG/RFC #3", 8  
RFCs (997, 1020, 1062, 1117, 1150, 1244, 1311, and 1543) refer to the  
RFC series as a "series of notes", that 623 RFCs contain the word  
"note" on the first page (but I didn't check all of them to see  
whether it was used as an adjective or as a verb), and that a related  
series was once entitled the Internet Engineering Notes, or IENs.

I dunno, what word would you suggest? Some documents refer to  
themselves as "memos" or "memoranda"... :^)

>   "IPv4, there is at a minimum IPv4 connectivity"

OK

> may be confusing for non-native English speakers.

I had rather hoped that these were obvious fractured quotes relating  
to widely-held principles. I'm not finding it on the web at this  
instant, but one of the various latin statements of Occam's Razor  
that I have run across translates as "a satisfactory proposition  
contains no unnecessary complexity". The Hippocratic Oath is often  
quoted as the source of "First, do no harm"; the words are in fact  
not found there, but might derive from a related work (also by  
Hippocrates) called "Epidemics", or from another work by Galen.  
Galen's words appear to have been "Primum non nocere".

If you would like, I can remove the word "first", or directly quote  
"Epedemics", which says "make a habit of two things—to help, or at  
least to do no harm".

(punching "Occam's razor" and "Hippocratic Oath do no harm" into  
google yields an instructive list of references, for those who are  
interested)

> broker, etc) or are they all end network based (like Tredeo, etc).

There are general comments on tunneling in:

     http://www.ietf.org/rfc/rfc2893.txt
     2893 Transition Mechanisms for IPv6 Hosts and Routers. R.  
Gilligan, E.
          Nordmark. August 2000. (Format: TXT=62731 bytes) (Obsoletes  
RFC1933)
          (Status: PROPOSED STANDARD)

and specific comments relating to ISP networks in:

     http://www.ietf.org/rfc/rfc4029.txt
     4029 Scenarios and Analysis for Introducing IPv6 into ISP  
Networks. M.
          Lind, V. Ksinant, S. Park, A. Baudot, P. Savola. March  
2005. (Format:
          TXT=64388 bytes) (Status: INFORMATIONAL)

The recommendation of the latter (section 3.2.2) is that the ISP run  
a native dual stack internally (ie, route both IPv4 and IPv6 prefixes  
using appropriate routing protocols, and forward both IPv4 and IPv6  
datagrams natively) and allow their customers to connect to that  
(section 3.2.3) using IPv4 initially and IPv6 later as they come up.

I can list a number of networks that have literally taken that  
approach. I can list a number of others that have operational  
concerns, and have chosen instead to run parallel IPv4 and IPv6  
networks internally, and either sell the customer separate IPv4 and  
IPv6 connections or split the traffic into those networks from their  
edge router. Perhaps half a dozen that I know of mention running an  
IPv6-only core and tunneling their IPv4 traffic over it. I obviously  
can't list my customers here, but if a network wants to identify  
itself, this would be a good time to do so... I make the point in 2.1  
that these networks don't bother me: within a single administration,  
they can make it operate correctly for themselves, their customers,  
and their peers.

What I *am* concerned about is the number of networks that are  
telling me that they want to run IPv6-only at this early stage in the  
transition, and the proposals being made for running IPv4 over those  
IPv6 networks. DSTM is one example; there are other approaches being  
discussed as well. In at least some cases, these are themselves  
networks of networks - a central IPv6-only core operated by one  
administration is tunneled by its customers (other administrations)  
to deliver IPv4 service among them. Here, I get very worried very  
quickly. While it will no doubt work well enough for those that are  
members of the club, interconnection with anyone else is not  
guaranteed. In other cases, I am being told by several networks that  
they expect to have limited IPv4 requirements and expect their  
supporting networks to make good things happen for them. However,  
since I talk with all of them, I know that they are supporting  
networks of each other, and can see that they aren't necessarily  
providing the supporting services to each other. Again, I get very  
worried very quickly.

I really want to hear that they all will run native IPv4 and IPv6  
routing and forwarding at their edges (eg, running dual stack  
networks), and not expect their customers to tunnel them. I really  
and truly want to hear that.

---

From: "Eric Klein" <[email-masked]>
Date: Tue, 16 Aug 2005 22:00:39 +0300

> themselves as "memos" or "memoranda"... :^)

Ok, I was thinking memo or document.

> google yields an instructive list of references, for those who are

I agree with your ideas in principle, I was thinking more along the lines
of:
"A satisfactory solution", "first, does no harm" and "contains no
unnecessary
complexity."

> > broker, etc) or are they all end network based (like Tredeo, etc).
<snip>

> and truly want to hear that.

I know that there was some "madated" conversions being discussed a year or
so ago (UK by 2008, Japan by 2010 etc - not sure about years for either) so
I was interested in seeing how these conversions would be affected by the
plans (i.e. early adoption of IPv6 only) before they were ready.

---

From: Tim Chown <[email-masked]>
Date: Wed, 17 Aug 2005 15:20:34 +0100

> plans (i.e. early adoption of IPv6 only) before they were ready.

UK by 2008?  Hmmm.  s/K/S?? :)

-- 
Tim/::1

---

From: "Eric Klein" <[email-masked]>
Date: Thu, 18 Aug 2005 11:04:57 +0300

> UK by 2008?  Hmmm.  s/K/S?? :)

As I was saying, the dates were from memory, if you have better information
I would love to hear about it. Especially in any country where the
government has put their 2 cents in about by when the conversion should
(must?) be completed.

Eric