[64] in SIPB IPv6
Re: IPv6
daemon@ATHENA.MIT.EDU (Noah Meyerhans)
Sun Dec 14 20:38:09 2003
Date: Sun, 14 Dec 2003 20:37:54 -0500
From: Noah Meyerhans <noahm@csail.mit.edu>
To: Simson Garfinkel <simsong@csail.mit.edu>
Cc: sipbv6@mit.edu
In-Reply-To: <00c101c3c27a$6ae55940$0901a8c0@e3>
--cvVnyQ+4j833TQvp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Dec 14, 2003 at 02:16:13PM -0500, Simson Garfinkel wrote:
> I'm writing an article about IPv6 for Technology Review; do you guys have
> any thoughts about when/if/why it is ever/not ever going to be deployed?
Hi Simson. We are supporting IPv6 unofficially in CSAIL right now, and
will fully and officially support it after the move to the Stata Center.
However, because main campus isn't supporting it, our external
connectivity is still via tunnels over IPv4. There are rumors that
CSAIL's independent commercial provider is working toward an IPv6
deployment, but I'll believe it when I see it.
As to when it will be widely deployed... I think it will be a while.
The DoD's Moonv6 project is a step in the right direction, and there's a
big push for it in Europe and Japan, but there are some major issues
with the protocol and deployment plans that the IETF has not yet worked
out.
The first problem has to do with multi-homing. There really doesn't
seem to be a solution that allows failover between links to different
providers using aggregatable provider-dependent addresses. It may turn
out that we'll end up seeing IPv6 multi-homing done the same way we
currently do multi-homing in v4: With globally routable addresses. It
may be a while before anybody admits this, though. For now, the
discussion of how to handle multi-homing with provider-dependent
addresses just keeps going in circles and isn't getting anywhere.
The other problem I perceive relates to dynamic addresses and DNS. IPv6
has had stateless autoconfiguration features since the very beginning,
but very little support for the necessary interoperability with the DNS.
It's often argued that, since IPv6 is a layer 2 protocol and DNS is an
application layer protocol that it isn't the responsibility of IPv6 to
handle DNS dynamic updates or nameserver discovery at all. That may
be true, but this problem is still blocking the adoption of the
protocol. There is a specification out there called DHCPv6-lite, which
is supposed to provide mechanisms for hosts to learn the IP addresses of
their nameservers, learn their hostname, and dynamically update the DNS,
just like we currently do with DHCP in IPv4. However, from what I
gather (I've not looked at the specification) the spec is something like
200 pages long an far more complex than any of the implementers care to
think about.
On the other hand, at this point basic support for IPv6 is very
widespread. It's on by default in MacOS X and a number of free Unix
systems, and is trivial to enable in Windows XP. Some application
support is still rather rough, but it's improving quickly.
In a lot of ways, the problems I described above can be ignored for now.
Big ISPs are likely to be given provider-independent globally routable
IPv6 netblocks, which avoids the multihoming issues, and the fact that
most people are going to be running dual-stacked systems (IPv4 and v6)
they can get their nameserver information via DHCP. Dynamic addresses
will probably simply not have entries in the DNS at all. The big
obstacles at this time are the fact that few (no?) commercial North
American ISPs offer IPv6 service at the moment, and home routers made by
Netgear, Linksys, etc do not support it. When those two problems
change, I suspect a lot of people will start using IPv6 without even
realizing it.
noah
--=20
Noah Meyerhans System Administrator
MIT Computer Science and Artificial Intelligence Laboratory
--cvVnyQ+4j833TQvp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/3RByYrVLjBFATsMRAi7fAKCL3oDQSF+Wii3hTQ9QMjd2HaLVTgCeMpcq
WXkHlEYeeXcL7V9q2hRc5gU=
=vqMe
-----END PGP SIGNATURE-----
--cvVnyQ+4j833TQvp--
