Subject: Re: Real life scenario - requirements (local addressing)

From: Dan Lanciani <[email-masked]>
Date: Thu, 7 Aug 2003 13:52:02 -0400 (EDT)

Pekka Savola <[email-masked]> wrote:

|On Thu, 7 Aug 2003, Andrew White wrote:

[...]
|> Real example: My ISP's DSL connection decides to drop the connection and
|> reconnect (with a new IPv4 address, and thus 6to4 prefix) every 1-3 hours. 
|> I'd rather not subject my internal network to that if I don't have to.
|
|Switch ISP or complain to them.  I certainly wouldn't bear with that kind 
|of behaviour.

It isn't clear that there will always be another ISP to switch to...

|If that kind of ISP techniques are commonplace, we may need to do 
|something.  But I'm not sure if that's the case.  Experiences?

I've brought up the notion of getting ISPs to change this business model
before.  Since the IETF can't mandate business models, any pressure would
have to come from the technical side.

|Note: consider how many of these techniques are used to prevent people
|from keeping servers at their home systems (i.e., does the ISP consider
|the changing address a bug or feature).

Given that forcing the address changes often requires extra work on the
part of the ISP (and you occasionally see requests from ISP folks for
better ways to shorten the address cycle :() I would assume that most of
this activity is designed either to discourage servers or simply to create
additional artificial levels of service.

|Also consider how the situation
|would change (if any) with IPv6 provided by the ISP.

Why should it change at all?  Similarly, why should the number of addresses
provided change?  ISPs that currently seek to detect and prevent NAT activity
are not doing so out of a sense of architectural purity.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------