From: Christian Huitema (huitema_at_no.spam)
Date: Tue Mar 19 2002 - 15:11:34 PST
> How will work, for example, a web browser with an IPv4 address in the
URL
> if you use BIS/BIA ?
The BIA would rewrite "connect AF_INET 1.2.3.4" to "connect AF_INET6
x:x:x::1.2.3.4", where x:x:x::/n is either the IPv4 mapped address
prefix (configuration less environment) or a prefix managed by a
specific NAT-PT (explicit configuration). The packets would be routed to
the NAT-PT, which would then do its stuff.
> >We may try to provide access to legacy
> >applications using a dual-stack mechanism,
>
> then you need an IPv4 address per host and manage IPv4 routing.
Well, there are two types of dual stack mechanism: an actual dual-stack
with, for example, two types of packets running over Ethernet, and a
DSTM like mechanism, in which the IPv4 packets are sent over IPv4. In
practice, I tend to believe that you need an IPv4 address per host in
both cases. As I wrote previously, I really don't believe in time
sharing, which implies that we should be ready to give a different IPv4
address to every node, even if we use 4over6.
Comparing multiplex over Ethernet or using 4over6 is not a black and
white thing. 4over6 let you save the management of IPv4 in subnets and
routers, but it introduces new components (servers and tunnels), and the
transmission of IPv4 packets between two local hosts is sub-optimal;
also, if you want to support old IPv4 only hosts, you will have to give
them some "real IPv4" infrastructure. It would be very nice to have a
clear picture of the target environment before we do the evaluation.
By the way, the "port range" option is probably not compatible with any
attempt to perform local communication. Think of two 4over6 nodes that
would happen to get the same address and different ports, and then try
to communicate. The results will be interesting. So, deciding whether
"local communication between legacy IPv4 applications" belongs to the
scenario or not is really an important issue.
-- Christian Huitema
This archive was generated by hypermail 2.1.7 : Fri Oct 06 2006 - 00:00:31 PDT