Subject: RE: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]

From: "Soliman Hesham" <[email-masked]>
Date: Tue, 16 Mar 2004 01:11:24 -0500

> -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]On
 > Behalf Of Alain Durand
 > Sent: Tuesday, March 16, 2004 12:39 AM
 > To: Pekka Savola
 > Cc: [email-masked]
 > Subject: Re: v6 deployment in general [Re: tunnel broker 
 > deployment [RE:
 > Tunneling scenarios and mechanisms evaluation]]
 > 
 > 
 > 
 > On Mar 15, 2004, at 1:11 PM, Pekka Savola wrote:
 > >
 > >> 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.  

=> Yes we can ! Why not? 

   ISPs just aren't offering static v4 addresses 
 > today 

=> Yes they are ! You just pay more for them.

Hesham

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Mar 2004 08:30:57 +0200 (EET)

I'm responding to both Alain and Hesham in the same message, hoping to 
reduce overload on the list..

[Alain:]
> I'm not sure I want to follow you here. If an application needs to
> be written to handle interface renumbering to benefit from IPv6 end
> to end connectivity, this is putting the bar fairly high.

Apps certainly shouldn't need to handle renumbering on the fly .. or 
so I would hope.  But they should not store information like "this is 
my static prefix, the next time I start, I will use it" either -- in 
each case, they should determine it independently.  I don't think 
that sounds like too high a bar.

[Alain quoting me:]
> > 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 :)
>
> In this scenario, we are already trying to fix the issue of ISP not
> cooperating to deploy IPv6... so I do not think it is unreasonable
> to seek to fix the address volatility problem at the same time if it
> is possible.

It is entirely different when the ISP does not *care* about IPv6, and
when the ISP is trying to *force* the user into a usage model (e.g.,
by renumbering the addresses used on the fly).  We're addressing the
first problem.  There isn't much we can do if the ISP e.g., filters
protocol-41 or the tunnel server UDP port at it's edge, for example.

Having to deal with the case where the ISP is harassing the user,
e.g., by the on-the-fly address changes is a complex problem.  If we
get a workaround for that for free -- that's fine.  If not, I don't
think we should try too hard.  In the end, the IETF is inevitably
going to lose to the ISPs who want to "encourage" their users to buy
their premium service..

>  > > don't think this is something we can guarantee even with native

I think you're missing the context here.  Would you build an 
application which would only work if the user's IPv6 address is 
static, and not for the others?

At least when I have coded apps, I have to design them to work with 
everyone :).

> => Yes they are ! You just pay more for them.

That's true of course .. but what do you think the user will choose,
if given a dynamic (or reasonably static) prefix for free, or having
to pay 5$/mo extra for a prefix which is guaranteed to be static?

I want the prefixes to be static as much as you do -- but I have
difficult time visualizing static prefixes to be so widely used that
applications, which could be run on all kinds of networks, could be
able to make an assumption that *all* the prefixes are static.  
Robust apps, especially if aimed at home users, just simply can't do
that AFAICS (I'd hope I was wrong..).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings