Hello,
In my Humble opinion this document is very interesting, for at least 6
reasons:
1/The mechanism "CPE mode " described in chapter 3 allows an IPv4 only
host running IPv4 only applications behind an "upgraded IPv4 CPE" to
initiate a communication with an IPv6 only server using a well-known
port and moreover, the server can also add a second session with this
host (for example to add a media flow).
I have not seen any other solution able to do that, but, may be, I have
missed them (For example in A+P solution an IPv4 only host can initiate
a communication with the IPv6 only host, with a shared IPv4, but only
using a port in the port range).
This is possible because a virtual IPv6 address is allocated to the
local IPv4 host behind the IPv4 CPE. This IPv6 address is made of 3
parts :
the IPv6 prefix of the IPv6/IPv4 gateway,
the Public IPv4 of the CPE ,
and the private address of the CPE.
So, as in normal IPv6 network, this virtual IPv6 address is identifying
the host behind the CPE ( not as in an IPv4 network where the host
behind the CPE is just identified by a port and the IPv4 address of the
CPE).
2/ To achieve that it is needed to includes 2 IPv4 addresses in the
virtual IPv6 address.
This could also be achieved with "6 to 4"+ISATAP technology. But the
problem comes from "6 to 4". This format uses a well-known prefix. But
with a well-known prefix, IPv4 routes are incorporated in IPv6 routers.
As, with IPv4 address depletion, IPv4 addresses allocation policy will
more and more driven by IPv4 addresses saving considerations than
routing optimization considerations, the number of IPv4 routes (the IPv4
entropy) will grow and it is important to avoid to introduce this
entropy into IPv6 networks.
So this solution needs an "ISATAP like" format with 2 IPv4 addresses.
Such format does not exist and this is the reason why this document
proposes a new format like a "6 to 4"+ISATAP but with a local prefix
instead of the well-known "6 to 4" prefix.
3/ In this document it is mentioned that the CPE must be upgraded toward
dual-stack. This condition is sufficient but not necessary.
In fact if you look carefully, it just needs IPv4 in IPv6 translation,
IPv6 in IPv4 encapsulation and address modification in DNS answer. All
theses processes can be done by simple header manipulations. This can be
done by a simple IPv4 network driver (No IPv6 routing or router
advertisement or DHCPv6 ...).
4/ Concerning the Dual-stack Mode, the condition that the host is
upgraded toward dual stack is also sufficient, but not necessary. In
fact it can also be done by a simple network driver as for the CPE. So
not only IPv6 applications can uses this technology but also IPv4 only
applications.
5/ The proposed format is consistent with the IVI format, so it is easy
to uses the same gateways for both cases.
6/ More, this format can be extended so that a common architecture with
only 2 kinds of function:
the IPv4/IPv6 gateway
the NAT function (this function receives IPv6 packet and return IPv6
packets)
This common architecture can then be used for :
IVI-T
IVI
IPv4/IPv6 translator
DS-LITE
A+P
So it is possible to build a common proposal to solve all different
cases. But this is another story and I am ready to discuss with the
authors of the IVI-T proposal to prepare a common draft.
Eric BURGEY
France-Telecom/Orange Lab
________________________________
From: Dave Thaler [mailto:[email protected]]
Sent: Thursday, July 23, 2009 8:20 Matin
To: [email protected]; [email protected]; [email protected];
[email protected]; [email protected]
Cc: [email protected]; 'Behave WG'
Subject: [Softwires] Comments on draft-xu-behave-ivit-00
I read this document and must admit I didn't understand it. :-(
What I understood is that it seems to basically say you can
combine translation + encapsulation in the same box, which is
what I believe the Dual-Stack Lite etc folks already say.
Attached is a marked up copy with my comments (mostly
illustrating my confusion).
-Dave
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires