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

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 15 Aug 2005 23:25:54 +0200

Hi Fred,

Nice document.

Overall, agree with your conclusions about 3.3, but I think there is one
more scenario, which is the one that we are facing, and seems to me the
right way to go, actually the natural one, being deployed with some of our
customers.

      ,---.                                                  ,---.
     /     \                                                /     \
    /       \                                              /       \
   ; IPv4+6  :                                            ; IPv4+6  :
   | Network |                                            | Network |
   :      +----+---.        ,---.       ,---.       ,---+----+      ;
    \     |GW-A|    \      /     \     /     \     /    |GW-D|     /
     \    +----+     +----+       \   /      +----+     +----+    /
      `---' ;  IPv6  |GW-B| IPv4   : ;  IPv4 |GW-C| IPv6   : `---'
            | Network+----+   +    | |    +  +----+Network |
      ,---. :Transition  :  IPv6   : :  IPv6  ,---.
     /     +----+A   /    \   B   /   \   C   /   \   D+----+     \
    /      |GW-A|   /      \     /     \     /     \   |GW-D|      \
   ; IPv4+6+----+--'        `---'       `---'       `--+----+IPv4+6 :
   | Network |                                            | Network |
   :         ;                                            :         ;
    \       /                                              \       /
     \     /                                                \     /
      `---'                                                  `---'

Network A and D are IPv6-only, with GW-A and GW-B taking care of the
v4-in-v6 tunneling, automatically.

Network B and C are either IPv4 and IPv6 (dual stack) or IPv4 and IPv6
(tunneled), but they appear to network A and D as dual stack.

This means that IPv6 traffic leaving the leaf networks will never be
"translated", even it can be tunneled in case B or C don't support native
IPv6.

Meanwhile, IPv4 traffic could be handled in several ways:
1) Tunneling 4-in-6 (from GW-A1 to GW-A2)
2) Tunneling 4-in-6 (from GW-A to GW-B)
3) Translation for some protocols, such as HTTP which typically are already
proxied, so we aren't adding an additional breach. Example an IPv4 only web
site located outside GW-B, is being proxied (v4 outside-v6 inside thru A)
and reached all the way via IPv6.

The point here is to have a UNIQUE 4-in-6 protocol which will work the same
in 3.2 than 3.3, otherwise we will have some troubles as more and more
networks (general internet) have only IPv6 support, which will happen sooner
or later.

Having a single 4-in-6 mechanism will avoid future problems. I think this is
part of the work that we started some time ago with the auto-discovering of
tunnel end points, v6tf and recently "softwires". Work already done could be
used here, such as DSTM.

One more comment. I've discovered a lot of confusion in several documents
regarding 6over4 and 6in4, which is being followed by confusing documents
from vendors. I think is very important to make a general recommendation,
may be not just to this WG, but in general to all the IETF documents which
mention tunneling, to clearly make a distinction between both mechanisms,
probably avoiding using "over" when actually is referring 6in4
encapsulation. Not sure if this should be raised at IESG level or whatever.
What do you think ?

Regards,
Jordi

------ Mensaje reenviado
De: "[email-masked]" <[email-masked]>
Responder a: "[email-masked]" <[email-masked]>
Fecha: Mon, 15 Aug 2005 15:50:01 -0400
Para: <[email-masked]>
Asunto: 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-Type: text/plain
Content-ID: <[email-masked]>

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

------ Fin del mensaje reenviado

************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Information available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Fred Baker <[email-masked]>
Date: Mon, 15 Aug 2005 14:47:02 -0700

On Aug 15, 2005, at 2:25 PM, JORDI PALET MARTINEZ wrote:
> Overall, agree with your conclusions about 3.3, but I think there  
> is one more scenario, which is the one that we are facing, and  
> seems to me the right way to go, actually the natural one, being  
> deployed with some of our customers.
>
>       ,---.                                                  ,---.
>      /     \                                                /     \
>     /       \                                              /       \
>    ; IPv4+6  :                                            ; IPv4+6  :
>    | Network |                                            | Network |
> Network A and D are IPv6-only, with GW-A and GW-B taking care of  
> the v4-in-v6 tunneling, automatically.

There are certainly cases in which a consistent transition strategy  
is being followed and is working. I think I said something in the  
document about granting that the use of a single consistent strategy  
that works will probably work :^).

What I am concerned about is the proliferation of inconsistent  
strategies, and the set of cases I can come up with in which they do  
not work. That is the issue I am trying to raise.

> One more comment. I've discovered a lot of confusion in several  
> documents regarding 6over4 and 6in4, which is being followed by  
> confusing documents from vendors. I think is very important to make  
> a general recommendation, may be not just to this WG, but in  
> general to all the IETF documents which mention tunneling, to  
> clearly make a distinction between both mechanisms, probably  
> avoiding using "over" when actually is referring 6in4  
> encapsulation. Not sure if this should be raised at IESG level or  
> whatever. What do you think ?

What you expect clue? :^)

Yes, it would be good if people would say clueful things in a clueful  
way. There is probably room for an internet draft on the subject.

---

From: Rémi Després <[email-masked]>
Date: Wed, 17 Aug 2005 09:22:09 +0200

Hi Fred,

I very much share the concern about end to end connectivity in the 
complex configurations that are being built for the coexistence of IPv4 
and IPv6 (Yref 
http://www.ietf.org/internet-drafts/draft-baker-v6ops-end2end-00.txt).

Indeed this was the main reason for my I-D 
http://www.ietf.org/internet-drafts/draft-despres-v6ops-transition-v5roadmap-00.txt.

After IETF63 in Paris I received about it this comment from Pekka 
Nikander:  

" It is  very hard to evaluate its potential technical merit; that 
would  take far too much time. I would encourage you to write more 
introduction, trying to  present the ideas without going into too much 
detail and without  using too much new terminology."

Here is an attempt at introducing the subject better.

    * During the v4-v6 coexistence period, there will inevitably be a
      mix of  hosts, customer routers, and provider services having
      various mixes of coexistence tools.
    * Due to the highly combinatorial nature of the problem, analysing
      in all cases which connectivities are possible, along which
      routes, and using which encapsulations, seems  beyond feasibility.
    * A simplified model would therefore be welcome if with it, for a
      well chosen set of standard coexistence functions in some hosts,
      edge routers and ISP gateways:
          o The above analysis would becomes tractable.
          o Extensive connectivity would be available, including for
            legacy v4-only and future v6-only hosts.
          o Selected routes and encapsulations would be optimum
            according to natural criteria.

The purpose of the I-D was to introduce an approach toward such a 
simplified model, covering in particular, but not only, IPvX networks 
across IPvY networks (X and Y being v4, v6 or v4 + v6).  

This model as it stands needs no new protocol. It only needs that:

    * a particular v6 address format be defined, upward compatible with
      all existing ones;
    * some code be added in those entities (hosts, customer edge
      routers, ISP gateways) which claim compatibility with the new
      address format. This code would have to be be carefully specified
      but, dealing with only a few simple concepts, would not be
      voluminous. It would maintain upward compatibility with all other
      existing coexistence tools.

If some edge routers and ISP gateways supporting the address format 
would be deployed, they would provide powerful v6 capabilities to 
concerned  customer sites, independently or in association with whatever 
transition tools other sites and ISPs may have deployed.  

Although the I-D is specific on a number of details (some of which are 
still bugged - my apologies!), the current proposal is just a tentative 
example of what could be worth standardizing to tame the beast.

It already appears, after IETF-63 that, STUN and Teredo should be 
integrated in some way in the model, and that the distinction between 
mobile and fixed IPv4 services would advantageously be replaced by that 
between global v4 address- and private v4 address- Wan services. (The 
latter implies one or several layers of v4 NATs in the ISP infrastructure).

Also, as you pointed out to me, the choice of "v5" to name an 
intermediate status between v4 and v6 is unfortunate because of various 
connotations. "vB" for example could be better, meaning (standardized) 
Bistandard. (Not to be confused with Dual stack, which would refer to v4 
and v6 side by side).

Is it appropriate that a discussion on this work starts here ?
I am not sure, but your contribution on the End to End Problem, and some 
of the points made about  DSTM, suggest it could be productive for IETF, 
at leat as long as the LRW BOF hasn't led to a WG.

Regards.

Rémi Després

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Aug 2005 12:58:17 +0300 (EEST)

>     existing coexistence tools.

Are you proposing is a format which needs to be (more or less) 
understood by the whole Internet ?

The evaluation of the scenarios where this is or isn't supported (and 
the mix of these) might call for a bit of description.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--1589707168-789498285-1124359097=:1622--

---

From: Rémi Després <[email-masked]>
Date: Thu, 18 Aug 2005 14:54:16 +0200

> understood by the whole Internet ?

Definitely not.
 (It would have been a very poor design option, right ? :-) )

When I say : "If some edge routers and ISP gateways supporting the 
address format would be deployed, they would provide powerful v6 
capabilities to concerned  customer sites, independently or in 
association with whatever transition tools other sites and ISPs may have 
deployed.", concerned customer sites are those where the edge routers 
has been upgraded to support the new format, and/or those that have 
acquired the right to use some gateways where the new format is supported.

Their additional connectivities may be incoming as well as outgoing, so 
that they benefit also to some correspondents of concerned hosts.

> the mix of these) might call for a bit of description.

Yes, certainely.
This is part of the next step.
In the mean time you could have a look at the attached slides.
They were prepared for a verbal presentation.
Although they are not self explanatory, Slides 11 to 16  could provide 
an insight into the kind of E2E paths  that become possible.

Thanks for your question and comment.
Please don't hesitate to ask for more clarifications.
I am aware they are needed, and it helps making progress.

Rémi Després

---

From: Tim Chown <[email-masked]>
Date: Fri, 19 Aug 2005 10:15:09 +0100

>    I am aware they are needed, and it helps making progress.

The stumbling block to me digging deeply into your work is the terminology
used.  It's not using conventional language and terms.

-- 
Tim/::1