On Wed, 13 Sep 2000, Dan Lanciani wrote:

[snip]
> discourage them from consuming it all.  Offer the v6 space on the terms that v4
> space was once available (i.e., free with nominal justification documentation)
> and I'm sure people will use it.
[snip]
> The same argument applies to NAT.  If ISPs make it expensive to get extra v6
> addresses (based on the justification that addresses used to be scarce?) then
> people will use NAT with IPv6.  If ISPs make "stable" v6 addresses (i.e., ones
> that they do not deliberately renumber frequently) a premium service then
> people will use NAT. 

Simple. Require that any group providing packet transport services (an
ISP) to provide address space to their users under the same set of
qualifications required for the provider to obtain address space at a
maximum.

This would be enforced by making compliance mandatory for address space
allocations (thus making the requirement recursive (i.e users of user of
users).

This would not effect a providers ability to otherwise sell transport
services under whatever contract their customers and they agree opon. 

It would also simplify justification documentation for providers, just
concatenate their user's justification documents with their own to form
their application.

I believe this is the only way to break the idea that network addresses
are a valuable commodity and to prevent NAT.

> Although the standard claim is that NAT breaks the end-
> to-end model we all like (and note that I have personally never liked NAT),
> NAT shines at preserving the stable-address model that is deeply embedded in
> many protocols and applications.  NAT has already proved itself:  many useful
> applications work just fine in spite of the loss of the end-to-end model.

NAT is abominable. It subtlety breaks things and hides the cause. It is
full of exceptions and gotchas. 

One layer of NAT can be manageable when the network is small and has only
a single outside path. 

However, as networks become large and better innerconnected, peering
address conflicts on NATed networks necessitate multiple layers of NAT
causing a complicated 'WHO's on first?' situation. Furthermore, the
statefulness required by many->one NAT (and one-one for some protocols) 
makes many types of highly-available configuration virtually impossible to
achieve. Indeed, virtually all NAT solutions force there to be a single
point of failure or a single site of failure.

NAT is a descent into madness.

> I happen to think that ISPs will charge a premium for multiple and/or stable
> v6 addresses because that is the status quo and because the market will bear
> it.

I agree unless they are required not to practice this harmful activity.

The legally required goal of a corporation is to maxmize shareholder
profits. This goal may at times conflict with the goal of providing a
global, scalable, available, and optimally useful network infrastructure.

Indeed, a heavily NATed internet enviroment would create many additional
network contracting and consulting jobs. 

> Thus, I suspect that NAT will remain quite active if/when IPv6 is deployed.

If it does IPv6 will fail. 
An IPv6 NATatopia would offer no benifit to consumers or providers over an
IPv4 NATatopia.

> I think this is unfortunate--again, I'm no fan of NAT--but it's probably too
> late to do anything.  While it certainly would have been possible to structure
> IPv6 in such a way that end users could allocate identity addresses independent
[snip]

> So the market pressures will continue to operate in an IPv6 environment just as
> they have in the IPv4 one.  All IMHO, of course...

I think the solution is obvious: If a detrimental behavior is expected
then simply forbid it. 

There is no point to being wishey-washey. Progress is not made by
the mediocre.

Gregory Maxwell

--
The comments and opinions expressed herein are those of the author of this 
message and may not reflect the policies of the Martin County Board of
County Commissioners.


--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------

Reply via email to