-----BEGIN PGP SIGNED MESSAGE-----

Iljitsch van Beijnum wrote:

> On 14 okt 2003, at 16:13, Mark Smith wrote:
> 
> > A little later, it occured to me that maybe what the market might be 
> > missing is a statement from the IETF, IESG and/or IAB, that IPv6 is 
> > now *ready*, and can be deployed in production via the available 
> > transition mechanisms, slowly replacing IPv4 (+ NAT). Maybe the market 
> > is really just waiting for the engineers behind IPv6 to say "it's 
> > basically finished, its now ready for you to use, pending your 
> > applications being ported".
> 
> But unfortunately, IPv6 _isn't_ ready. See the site local debate. See 
> the flowlabel goings-on. See the multihoming problem. I'm not 
> sure what the status of DHCPv6 is except that I haven't seen it in the wild 
> anywhere yet.

There is at least a Linux implementation in the wild:
http://sourceforge.net/projects/dhcpv6

And there is a quite-empty page at http://www.dhcpv6.org

> And there are no reasonable other ways to dynamically 
> find DNS servers in IPv6.

I would really like to see a 'default' IP address for DNS.
Anycast comes to mind here btw...

> That's all protocol stuff. Hopefully all of 
> this can be fixed in the not too distant future. But there there is 
> another extremely important issue that (in my not so humble opinion) 
> must absolutely be fixed before making any such statement: 
> the DNS. It 
> is currently impossible to resolve DNS names over IPv6 transport, 
> because the roots don't support IPv6 transport, none of the 
> major gTLDs supports IPv6 transport and very few, if any, TLDs
> support IPv6 glue records for delegated domains.

Apparently there is work being done on this, but it is not very public.
We have www.rs.net providing this for some time, but unfortunatly
it has some issues: it doesn't allow 'access' to non-IPv6 capable
domains and there isn't a european part of that deployment; yet, I understood.

> Some good multihoming wouldn't suck either, but since most end-users don't 
> multihome this doesn't have to be a hard requirement

I would really like to see this, but indeed it isn't a showstopper.
It is a requirement for some "hosters" though, but as can be
seen from the TLA allocation lists even 'smaller' ISP's get a TLA
so that should not be a problem either. Basically if one can say
they have 200 clients they have a done deal. Thus the only
requirement for multihoming is for endusers, even if those are
very big organisations. As IPv6 deployment isn't that far (yet)
they probably can't find two uplinks at the moment anyways.

<SNIP>

> > b) Is IPv6 good enough yet ?
> 
> Not yet... but we're making progress.

Seeing that usage and traffic at tunnelbrokers is growing I think
it is really catching on. There are two issues though that are
mostly a chicken and egg problem:
 - Hosters don't support it because clients don't have it -> money
 - Clients can't use it because Hosters don't support it.

Client access and for some also hosting is taken care of by
using tunnelbrokers and other transition mechanisms. ISP's
should start enabling IPv6 on their native networks where
possible and start providing servers with IPv6 connectivity.
Then it is at least possible for clients to use it.
RIPE got a big 'awww' when they enabled their whois service
to support IPv6 as to the number of requests that suddenly
started to come in over IPv6 :)

So kick your ISP, access and hosting, to get doing IPv6 and
if the access to that ISP can't provide native IPv6 ask them
to set up a tunnelbroker system, 6to4 relay etc for solving
that problem.

Greets,
 Jeroen

-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / [EMAIL PROTECTED] / http://unfix.org/~jeroen/

iQA/AwUBP40bRCmqKFIzPnwjEQJ+CgCePg8NuaQVdeAwfJTeYsJWmszrmpcAnRrx
Pp3fcBn6Z8+/OhXdojHhlMVO
=t+x3
-----END PGP SIGNATURE-----


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to