Subject: Re: IPv6 adoption behavior

From: Dan Lanciani <[email-masked]>
Date: Tue, 14 Oct 2003 22:54:28 -0400 (EDT)

Keith Moore <[email-masked]> wrote:

|On Tue, 14 Oct 2003 18:11:24 -0400 (EDT)
|Dan Lanciani <[email-masked]> wrote:
|
|> IPv6 offers absolutely nothing as a
|> replacement for NAT's primary function:  isolation of the customer network
|> from the (typically business-driven) address policies of the service
|> provider(e.g., cost, limits on number and stability, etc.).
|
|NAT isolates customer networks from upstream address policies only by severely
|limiting their functionality.

Clearly many users care a lot about the isolation and little about the
functionality that you believe is being limited.  Rather than trying to
convince them that they are wrong for wanting to keep their networks
running, how about proposing a way to achieve that isolation without
limiting the functionality that you want to preserve?  If we cannot
implement such a solution (and I doubt that we can since it changes the
economics of address rentals), do you really think it is reasonable to
demand that everyone give up what they need to have what you think they
should want?

|The functionality of an IPv6 network is better
|than that of a NATted IPv4 network even if the IPv6 address changes
|frequently.

To paraphrase your comments on host-based source routing, the functionality of
an IPv6 network whose addresses are changing frequently enough to make its
users' applications unusable is nil.  Conjecture: ``frequently enough'' likely
isn't all that frequently.  We just don't have the tools and models for dealing
with addresses changing out from under applications.  Even if we did, I've yet
to see any commitment from apps folks that they would be willing to deal with
such changing addresses.  And I think that dealing with changing addresses is
a much harder problem for an application than dealing with scoped addresses.
It's also something that will have to be handled by all applications, not just
those using referals.

|However I agree that we  need to define some expectations about address
|stability - both to serve as models for service agreements between customers
|and ISPs, and to serve as guidance for applications developers.

Ultimately, I believe that stability is a binary property.  Either someone
other than the owner of the network can change the address or they can't.
Anything that depends on the provider (and its provider and so on) to neither
screw up nor decide to change terms for economic reasons is not stability.

				Dan Lanciani
				ddl@danlan.*com

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

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 15 Oct 2003 22:23:20 -0700

Dan Lanciani wrote:
> ...
> ... do you really think it is reasonable to

A quick look at the archives for this list will show that he does (along
with several others).

That said, there are multiple parts to the isolation issue, and even though
most NAT implementations combine them, the discussion will be more
constructive to keep them separate.

The internal app address stability issue is what the whole SL discussion is
about, so refer to those threads for details.

The access control feature is something any router can implement, so
mangling the header is not the requirement for isolation.

Concerns about tracability are dealt with by RFC 3041 addresses.

That leaves address stability for external application use, in both a
'provider might change it' and multi-homing case. While a 'well written
(tm)' app would not be aware of the mundane details of transport addresses,
there are very few of those in the wild. Usually due to a belief that the
app programmer can do a better job than the stack & remote infrastructure. I
agree with you that getting apps to deal with addresses that might change
under them is a bigger task than scoping, or even the effort to port to IPv6
in the first place. That by itself does not necessarily lead us to IPv6-NAT,
but if IPv6-NAT looks like the lowest cost route to acheive address
stability, it will happen. Said another way, removing one of the required
attributes of stable addresses makes IPv6-NAT more likely, not less.

The sad part is we have the tools to provide a lower cost & higher feature
path for all but the multi-homed case (and a couple of proposals to deal
with that as well), but can't get past the irrational fear of & trusting
dependence on NAT. Until we get some applications to lead a few sample
network deployments that show all of the isolation issues are dealt with in
ways that don't require an IPv6-NAT, we will be stuck in an endless debate.

Tony

---

From: "Christian Strauf (JOIN)" <[email-masked]>
Date: Thu, 16 Oct 2003 08:16:06 +0200

> demand that everyone give up what they need to have what you think they
I don't think that it is about giving up what you need. With a combined
v4/v6-capable firewall- and v4-NAT box you could easily achieve the same
level of isolation of a subnet but without the restrictions for IPv6
hosts that are forced on v4-hosts by v4-NAT. (In this case: if you want
to be dual-stacked you keep v4 NAT and use v6 with appropriate firewall
rules.) So this should not be much of a problem.

However, I absolutely agree with what you said about IPv6 address
changes. I guess it is all about taking the choice of the addresses away
from the applications in some way or the other (e.g. by stuffing it into
the IP-stack of the system). One could also stay on the application
level and create a reliable and portable standard library that handles
the address issue transparently for the more abstract app that uses it.
This would clearly help application developers a lot. There exist a few
such apps and libs that already try to deal with this problem. Of course
there will always be some cases where an explicit choice of the
transport address may be useful but this does not speak against an
application independent solution to this problem.

Christian

P.S.: The "choice of address" issue is obviously a similar issue in
dual-stack environments. Right now, most v4/v6-capable applications are
almost unpredictable when it comes to choosing a v4 or v6 address and
falling back to one or the other (if that is an option) because it's up
to the developer's taste how to do it.

-- 
JOIN - IP Version 6 in the WiN  Christian Strauf
A DFN project                   Westfälische Wilhelms-Universität Münster
http://www.join.uni-muenster.de Zentrum für Informationsverarbeitung
Team: [email-masked]      Röntgenstrasse 9-13
Priv: [email-masked]    D-48149 Münster / Germany
GPG-/PGP-Key-ID: 1DFAAA9A       Fon: +49 251 83 31639, Fax: +49 251 83 31653