[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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: "Internet-Drafts@ietf.org" <Internet-Drafts@ietf.org>
Responder a: "Internet-Drafts@ietf.org" <Internet-Drafts@ietf.org>
Fecha: Mon, 15 Aug 2005 15:50:01 -0400
Para: <i-d-announce@ietf.org>
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
i-d-announce-request@ietf.org 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:
 mailserv@ietf.org.
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: <2005-8-15142046.I-D@ietf.org>

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
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.