> It's relevant unless you eliminate 6to4 and any other scheme that
> generates portable v6 address space from v4 space. 6to4 is actually
> rather interesting in that it has the potential to overtake "native"
v6
> addressing (especially considering Microsoft's treatment of 6to4 as a
> first-class citizen).
The main advantage of 6to4 is that we can jumpstart IPv6 quickly,
without requiring any tunnel configuration. We get a solution that is as
easy to deploy as a NAT, but which does enable global addressing and is
thus markedly superior in several important communication scenarios,
e.g. peer-to-peer applications, voice and video communication,
multi-player games.
Note however that these scenarios do not require "portable" addresses.
Most of the interesting applications come with their own rendezvous
mechanism, such as dynamic registration of peers in Napster or Gnutella,
SIP proxies for voice or video, lobbies for game players. Dynamic
addresses are fine, as long as they are global.
By the way, this means that we will get two kinds of ISPs: if an ISP can
provide a home with at least one global address, then we can start
enable IPv6 in the home with 6to4, and thus enable the applications. On
the other hand, if an ISP only provides the home with a non-global
address, e.g. a net 10 address, then a number of interesting
applications will not work. I suspect that this will create some form of
market pressure.
> Once 6to4 has served its purpose of jump-starting IPv6 deployment and
the
> time comes to kill it off in favor of native aggregated addressing,
the
> task may be more difficult than was anticipated. If the bulk of users
are
> on the 6to4 side, simply severing ties to the native backbone won't do
the
> trick since that would hurt the native users more than the 6to4 users.
It
> would instead require action on the v4 backbone to block the
encapsulated
> 6to4 traffic, and that might raise some eyebrows.
There are two answers to this question. A first one is to make the
interoperation between 6to4 and "native v6" as seamless as possible;
this is precisely why NGTRANS adopted the "6to4 anycast" draft, so that
we could deploy 6to4 boxes that automatically find a default route to
::/0; this draft is in the RFC editor's queue, pending IANA processing.
A second one is to enable the "6to4 boxes" to automatically receive an
IPv6 address prefix from an ISP, and then be able to propagate that
prefix to a local network, e.g. a home network. If we had that capacity,
then the "box" could be programmed to not start the 6to4 operation if it
can find a better, native, alternative. We can more or less do this
today in a clunky way, through a mix of PPPv6 and router advertisements;
we are lacking a properly engineered standard. Indeed, this standard
would be particularly helpful for the ISPs who, for some reason, cannot
provide global IPv4 addresses to their users.
As for the other consequences of 6to4, the main one will be to raise
expectations. 6to4 enables a user to derive an IPv6 prefix from a single
global IPv4 address. Many solutions will be using this capability, e.g.
providing global addresses to multiple devices, or using multiple
addresses for different functions within a single computer. This imply
that the "native v6" ISP will be expected to provide users with a
prefix, not a single host address -- otherwise, the native v6 solution
will be perceived as inferior to the existing 6to4 solution.
-- Christian Huitema
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
