Subject: RE: IPv6 adoption behavior

From: Dan Lanciani <[email-masked]>
Date: Thu, 16 Oct 2003 03:32:36 -0400 (EDT)

"Tony Hain" <[email-masked]> wrote:

|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.

I used to believe this, but I recently came to the realization that isolation
from provider address policy is a single issue.  Attempting to pigeonhole
each aspect of that isolation (and offer limited solutions) encourages a
divide-and-sweep-under-the-rug attack.  Unfortunately, even those who are
strongly supportive of what they see as an important aspect of policy isolation
often ignore aspects that are important to others.  N.B. I'm not saying that
NAT defines the model for isolation.  Most NAT implementations combine most
(or even all) of the required address policy isolation with a number of other
features.

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

Umm, yes, I think I participated enough in those threads that I do not need
to refer to them again...

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

I agree that access control is not a part of address policy isolation.

|Concerns about tracability are dealt with by RFC 3041 addresses.

I have my doubts about this; it may backfire.  If you tell your ISP that you
need more privacy it may be happy to oblige by increasing the frequency with
which your single valid address changes.  Be careful what you wish for.

|That leaves address stability for external application use,

It also leaves address rental cost, and limitations on number of addresses
available regardless of what you may be willing to pay (at least within a
class of service).  It probably leaves other things that I am forgetting.  I
think this is a good illustration of the pigeonhole pitfall.  If you fail
to address any one aspect of isolation and that aspect is important to enough
people, a NAT solution will appear to fill the void.  That solution will likely
include all the "bad" features of NAT as well simply because it's easy and
people already understand the model.

The core issue appears to be that any comprehensive solution to the isolation
problem would disenfranchise the address allocation hierarchy (just as simple
PI allocation would), and we aren't prepared to do that.  This rules out
obvious solutions like source routing (aka identifier/locator separation).  It
also lobbies against overlay networks and similar work-arounds.  Site-locals
as originally defined could have been tweaked to remove ambiguity and support
a large overlay network (there were plenty of bits) while the replacements we
are hearing about (if they come to exist at all) will likely have sufficient
punitive semantics to block such use on any interesting scale.

In some sense, the elimination of site-locals (and scoping in general) may
be a good thing.  Remember, the question being discussed was whether IPv6
can provide a substitute for IPv4+NAT.  At least this way the answer is
unambiguous, and deployers will be able to plan accordingly.

|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.

Absolutely.  It's a very hard problem to solve.  And (although I've asked
repeatedly during the site-local debates) I've yet to hear any assurance
from the application folks that they are even going to try.  I fear that
complaints of application failure due to address fluctuations will be met
with suggestions to use a different ISP and/or send your ISP more money.

				Dan Lanciani
				ddl@danlan.*com

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Oct 2003 14:28:46 +0200

Dan Lanciani wrote:
> from provider address policy is a single issue.  

Perhaps, but it is not an issue to which NAT is the only answer. In IPv6 we have
enough address space to solve it without NAT. 

   Brian

---

From: Geoff Huston <[email-masked]>
Date: Fri, 17 Oct 2003 06:07:42 +1000

>enough address space to solve it without NAT.

This is one more round in a circular argument. Yes, there is more than ample
address space, but there is a common perception that there is not ample
routing space.

It seems to me that there are a set of very loosely coordinated efforts in this
space, that are all, ultimately, directed at the same issue - attempting
to avoid placing fatal pressure of the routing system.

On the one hand there is an effort to constrain the supply of discretely
routeable elements through:
    policy constraints on the allocation of provider independent address space,
    use of "private" address space coupled with public NATs,
    consideration of various forms of scoped address architecture, and
    use of tunnelling and encapsulation.

At the same time we're attempting to drive an effort to improve the
scale of the routing system through a number of research related efforts
that attempt, in various ways, to scale routing by looking at the routing
domain as a  synchronized discovery of topology, policy and address
prefix reachability.

At the same time we see vendors making continual improvements
in router architectures and their components that lift the practical ceiling
of routing capability at a scale that appears to continue to track a
reasonable approximation of Moore's Law.

Coupled with continual improvement in operational environments that
have, on the whole, created improvements in the stability of the routing
environment.

I have the _personal_ impression that we've managed to overdamp the supply
of address prefixes such that the current routing system is now
situated very comfortably within the current capabilities of the routing
system and the underlying active network elements, but at the cost of
increasing application complexity in a world of NATs, dual protocol
stacks, multi-homing, mobility, and so on. Its not entirely clear to me that
this approach scales. My impression is that we've not managed
to push the scaleability of routing technology at the same time, so we've
fixated, perhaps too far, on  applying constraints within the address system
and paying the cost through increasing application and service
architecture complexity.

If we had more confidence  in the ability to scale the routing system we could
look beyond the relative merits of various forms of application of address
system constraints and strike a better balance between carrying the load
of further network scaling between the routing and addressing systems.

Geoff

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 16 Oct 2003 16:55:02 -0700

Dan Lanciani wrote:
> ... Attempting to pigeonhole
> divide-and-sweep-under-the-rug attack.

Recent evidence around the IETF supports this claim, but in the real world
where NAT is seen as the single solution to all the problems, we need to
break them down to show the alternative solutions to each.

>  Unfortunately, even those who are
> often ignore aspects that are important to others.

If I missed something it was only for lack of awareness. Please send details
off line.

> ...

Just trying to be complete without rehashing ;)

> ...

If a provider is going to offer me a single address, I will insist on a
globally routable IPv4 one, then push their service down a layer with the
other (irrelevant to the end user) lower layer wrapper technologies. If they
do the right thing and provide a prefix, there is no need for them to know
about the site privacy policies. My point was targeted more at those that
claim nat obscures the origin host, therefore provides some degree of
privacy isolation.

> class of service).

Current policies are fed by the resource scarcity, which over the short term
is artifical, but over the long term is real. We haven't gotten the correct
version at the nav6tf web site yet, but a paper there will show that we will
need well over 400 additional /8's to get a single address to 20% of the
population outside the countries that already have one or more for 20% of
theirs. This is for an HD ratio of 90% which is well in excess of the pain
threashold documented in RFC3194. Taking that down to current practice of
85% more than triples the number of /8's required to well over 1300. And
again, that is only to provide one address to 20% of the population in those
countries that don't already have that many.

Take scarcity off the table, and it will be difficult to maintain per
address costs if there is any competition in the environment.

> It probably leaves other things that I am forgetting.  I

I agree, so we need to be documenting all the cases we can find for why
network managers will demand isolation from SP provided addresses.

> PI allocation would), and we aren't prepared to do that.

I agree that some approaches will disenfranchise some historical
institutions, but I don't think that is what is holding us back. There is
also an irrational fear of policy intervention (read that as ITU), which
would make the PI approaches like mine or the city focused ones tractable to
the routing system.

> This rules out

That is why I have lobbied that we need to be solving both the local use &
the PI problems at the same time. They solve different problems, but if we
only provide one, it will be abused to solve the other.

> unambiguous, and deployers will be able to plan accordingly.

Well just because the IETF buries its collective head in a dark place does
not mean network managers will do away with scoping. After all the IETF
definition is just a formalization of the hacks they were already doing.

> with suggestions to use a different ISP and/or send your ISP more money.

I really don't care if the ISP gets more money, as long as those responsible
for the lack of alternatives are the ones footing the bill. It is good to
have a financially healthy ISP to rely on, just not at my expense ...

Tony