[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]
To be honest, unfortunately, even if we have a "killer" application, I don't think, at least not initially and quickly, we will have access networks with native IPv6 support.
The backbones, yes no problem for most of them, but access will take some more time. One of the problems is that we don't have cheap xDSL or cable CPEs with native IPv6 support (but are on the way).
So I expect that initially even actual applications, that don't get wide usage with IPv4 because the limitations, NAT and so on, will come to live with IPv6. I actually use one of these, as I've all the devices, lights, windows, alarm, ... accessible with IPv6, so I can even provide water to my dogs, and look at them with IPv6 cameras. In San Diego I can show it in the v6ops session or the coffee break if someone is interested ;-)
That was impossible with IPv4, but easy with IPv6.
Regarding the ISPs that keep changing the address, this can be easily solved with our "auto-trans" idea..
Regards,
Jordi
----- Original Message -----
From: "Pekka Savola" <pekkas@netcore.fi>
To: "Alain Durand" <Alain.Durand@Sun.COM>
Cc: <v6ops@ops.ietf.org>
Sent: Monday, March 15, 2004 10:11 PM
Subject: Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]
> On Mon, 15 Mar 2004, Alain Durand wrote:
> > On Mar 15, 2004, at 10:07 AM, Pekka Savola wrote:
> > > It might not hurt, but the applications and the systems must IMHO be
> > > designed to deal with the situation that when they (re)start, the
> > > address might be different. I.e., the lifetime of the address does not
> > > *necessarily* have to be longer than the lifetime of the application
> > > process.
> >
> > The "application" may be more complex than just one process.
>
> Agree.
>
> > Stable addresses across reboot may be necessary.
> > I want to be able to build apps that take advantage of the large IPv6
> > address space and consider that addresses are stable.
>
> So, you want to build a simple application. Don't we all.. :) But I
> don't think this is something we can guarantee even with native
> access. ISPs just aren't offering static v4 addresses today even when
> they'd have technical means to do so. So, counting on static v6
> prefixes would IMHO be cutting corners too much.
>
> The problem is worse with transition mechanisms, especially the ones
> which traverse NATs, but the situation may improve as soon as we can
> get rid of them. In any case, such mechanisms can provide a stable
> as long as they can keep the NAT/IP mappings stable -- which is, for a
> properly designed application, maybe sufficient.
>
> > > On the other hand, as long as John Doe's home PC stays powered on and
> > > connected to the Internet, his address should stay stable.
> >
> > I suppose that you are aware of ISPs that change DHCPv4 allocated
> > addresses every 24 hours... If John Doe's computer build its v6
> > address form those volatile v4 addresses, its v6 address will also
> > change very 24 hours, and this even though John Doe has not rebooted
> > his PC. Not good.
>
> Yep, I know this -- unfortunately. But there is little that can be
> done to fix ISPs which want to enforce the users not to do Foo
> (whatever Foo may be). We can hardly fix the misbehaving ISP problem
> at the IETF.. as you're probably well aware :)
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.