Subject: Re: AN interesting article. FYI... contd

From: Dan Lanciani <[email-masked]>
Date: Sat, 4 Sep 1999 00:22:42 -0400 (EDT)

Thomas Narten <[email-masked]> wrote:

|Philosophical desires aside, the reality today is that the IPv4
|addresses are no longer the stable identifiers that folks find
|covenient. Wishing it otherwise won't make it so.

I would have to disagree with this at least in part.  IPv4 addresses
remain the stable identifiers that they always were because no good
alternative has been offered.  Those who own portable address space
continue to find this convenient, while those with ISP-specific CIDR
addresses find it a disincentive to switching ISPs.  The question is
whether we really wish to make the latter case (and current status quo)
the standard for all IPv6 end users.

[snipping description I agree with]

|How to do the mapping in a world where network address can change is a
|very hard problem, if one wants a solution that scales to the size of
|the Internet.

I agree completely that this is a very hard problem.  I also have my doubts
that it can be pushed onto the DNS without significantly changing the DNS
as we know it.  My main concern, though, is that the problem will be avoided
rather than solved.

Towards the beginning of the development of IPv6's hierarchical address space
the general notion seemed to be that nobody would get stable, portable address
space and that sites could be renumbered almost on a whim.  This model carried
with it the strong implication that the stable identifier problem (which really
encompasses the tcp session stability issue and many other similar issues)
would have to be solved before the protocol would be of any use to anyone:  the
new addresses were by definition not usable as stable identifiers.  Now several
years later IPv6 is starting to be deployed (ok, maybe just for testing) and
the problem remains unsolved.  Because a complete solution may well require
fairly deep changes, I worry that its implementation is becoming very unlikely
as the protocol becomes more fixed.

Moreover, we seem to be talking about giving ISPs portable IPv6 address space
for multi-homing, and this will conveniently solve the stable identifier
problem for ISPs at the same time, thus removing pressure to implement a real
solution.  (Consider that the multi-homing problem is in many senses the same
as the stable identifier problem.  You need a way to identify your site as a
destination for packets independent of the low-level address hierarchies in
which it is participating at the moment.  Both problems might be solvable with
a single mechanism and then multi-homing would not have to provoke a need for
special address space.  I realize that I'm talking at a fairly high level of
abstraction here and that such a solution would represent a radical change in
direction that is virtually impossible at this stage.  But it is interesting
to consider a model where end users are not strictly dependent on an address
management bureaucracy.)

If things continue in the direction they seem to be moving, the net effect
may be to enshrine in IPv6 a model that was supposed to be a temporary hack
to deal with table size in RAM-starved routers.  IPv6 addresses will be the
first-class citizens of identity (because there is no alternative), but end
users will be unable to allocate them statically.  Enterprise managers may not
be so quick to embrace the new protocol with only a promise of a later solution
to the stability problem.  Obviously it won't matter to the average dial-up
user who already has a dynamic address (not that such users would have much
say in the first place) and ISPs won't mind if they are getting portable
address space.  Network managers currently using stable, well-tested solutions
like NAT may make for a hard sell unless specific advantages can be presented
to justify the expense of an upgrade.  There is also the concern about paying
a (possibly increasing) address fee for all the machines that were previously
behind the NAT:  even though the IPv6 address space is vast, it's structure
makes it subject to at least the perception of localized scarcity that could
be used to justify high prices to end users.  It would be unfortunate to
switch to IPv6 only to have to switch again to NAT'ed IPv6 for cost reasons.

Anyway, I hadn't intended to ramble on about this.  As I said, I was playing
devil's advocate to point out that IPv6 acceptance isn't quite a no-brainer,
and that the strategy of comparing to current addressing solutions is by no
means a knock-down argument.  I will now return to quietly watching IPv6
progress. :)

				Dan Lanciani
				[email-masked]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

---

From: Peter Tattam <[email-masked]>
Date: Sat, 4 Sep 1999 14:48:57 +1000 (EST)

A very well put together argument.  You understand the issues well.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Jeff Williams <[email-masked]>
Date: Fri, 03 Sep 1999 22:10:28 +0100

Dan and all,

  Dan, you make some very good and complexing points and problems
that I have seen with IPv6 and more importantly with how those
addresses will be allocated.  Currently ICANN is considering
"Taxing" IP addresses, and they will likely start out with IPv6
addresses.  This makes acceptance and portability a
much more serious concern.

> means a knock-down argument.  I will now return to quietly watching IPv6

Regards,

--
Jeffrey A. Williams
Spokesman INEGroup (Over 95k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

---

From: Thomas Narten <[email-masked]>
Date: Tue, 07 Sep 1999 15:59:06 -0400

> addresses find it a disincentive to switching ISPs.  

I think we are more in agreement than disagreement. Folks would like
for addresses to be stable identifiers, because they seem to be the
closest thing available today. At the same time, those who don't have
portable addresses are stuck with the realities that come with that
(e.g., lack of permanence for those addresses). But whether we like it
or not, global addresses are becoming less "stable" as
identifiers. This can't be just wished away.

> The question is whether we really wish to make the latter case (and
> current status quo) the standard for all IPv6 end users.

What is the alternative? I agree that this is an undesireable state to
be in. But going back to the idea that everyone's addresses are
portable isn't tenable either. Routing in the backbone would not be
able to handle it (i.e., it doesn't scale even today, much less into
the future). What you seem to be asking for is a solution to the core
problem that no one has yet been able to come up with a solution for:
How can we make renumbering painless enough to carry out so that it
can be done on a regular basis (so that routing information can be
sufficiently aggregated and backbone routing protocols can deal with a
managable number of routing prefixes), yet at the same time have a
stable identifier that end hosts can use in place of addresses?

IPv4 hasn't come up with a solution to this problem and neither has
IPv6. Saying we must solve this problem in order to make IPv6 viable
doesn't change the reality that there is no concensus on how (or even
whether it is possible) to solve the problem.

And it is the case that v6 has taken steps to make it easier (not
trivial, however) to renumber a site. But the notion that we'll be
able to renumber sites frequently and with no disruption to end sites
is fantasy IMO. Wishing it otherwise won't make it so.

> I agree completely that this is a very hard problem.  I also have my
> doubts that it can be pushed onto the DNS without significantly
> changing the DNS as we know it.  My main concern, though, is that
> the problem will be avoided rather than solved.

But is this problem solvable today? There is disagreement today
whether this is an engineering problem or a research problem. If it is
really the latter, the implication is that we don't yet know how to
solve the problem.

> Towards the beginning of the development of IPv6's hierarchical
> address space the general notion seemed to be that nobody would get
> stable, portable address space and that sites could be renumbered
> almost on a whim.

I think this is a misconception (shared by many unfortunately). I
don't think anyone who has spent a lot of time working on v6 thinks
renumbering can be done "almost on a whim". Some folks wish this were
the case, just like they wish IPv6 did a lot of things that it doesn't
do (and never set out to do).

> This model carried with it the strong implication that the stable
> identifier problem (which really encompasses the tcp session
> stability issue and many other similar issues) would have to be
> solved before the protocol would be of any use to anyone: the new
> addresses were by definition not usable as stable identifiers.  Now
> several years later IPv6 is starting to be deployed (ok, maybe just
> for testing) and the problem remains unsolved.  Because a complete
> solution may well require fairly deep changes, I worry that its
> implementation is becoming very unlikely as the protocol becomes
> more fixed.

> Moreover, we seem to be talking about giving ISPs portable IPv6
> address space for multi-homing, and this will conveniently solve the
> stable identifier problem for ISPs at the same time, thus removing
> pressure to implement a real solution.

Could you explain a bit more? Why do you think we are giving ISPs
portable address space? I believe only the TLA prefix is truly
portable, and ISPs do not automatically get them.

> (Consider that the multi-homing problem is in many senses the same
> as the stable identifier problem.  You need a way to identify your
> site as a destination for packets independent of the low-level
> address hierarchies in which it is participating at the moment.
> Both problems might be solvable with a single mechanism and then
> multi-homing would not have to provoke a need for special address
> space.  I realize that I'm talking at a fairly high level of
> abstraction here and that such a solution would represent a radical
> change in direction that is virtually impossible at this stage.  But
> it is interesting to consider a model where end users are not
> strictly dependent on an address management bureaucracy.)

I agree that site multihoming/renumbering are very similar and related
problems.  The current IPv6 addressing architecture (e.g., split of
addressess into "routing goop" and EUI-64-like portion) and the large
v6 addresses make it quite possible to still make changes. Not changes
to the "base" so to speak, but there is certainly room for
experimentation with the possibility of full migration later on.  The
difficulty so far has been coming up with something to exploit new
approaches that folks agree we should pursue. While I sympathize with
the feeling "this problem needs to be fixed", someone still needs to
come up with a solution.

> If things continue in the direction they seem to be moving, the net
> effect may be to enshrine in IPv6 a model that was supposed to be a
> temporary hack to deal with table size in RAM-starved routers.  IPv6
> addresses will be the first-class citizens of identity (because
> there is no alternative), but end users will be unable to allocate
> them statically.

I don't understand what you mean by the above. Do you mean "go to IANA
and get a portable address block" from which one can assign addresses?
That day is gone.

> Enterprise managers may not be so quick to embrace the new protocol
> with only a promise of a later solution to the stability problem.

Let us be honest, there is no "promise" that there will be a
solution. There is "hope", but no "promise". Who is making such a
promise? And when I say "hope", I mean that solving this problem has
not been ruled out. But I am not aware of anyone actively working on
this particular problem either at this time.

What folk (i.e. IPng) are working on now is multihoming that makes use
of multiple prefixes/addresses on end hosts. This doesn't have all of
the nice properties that portable addresses have (to the end host),
but it is consistent with keeping backbone routing stable and
manageable (which portable addressing does not do).  

> Obviously it won't matter to the average dial-up user who already
> has a dynamic address (not that such users would have much say in
> the first place) and ISPs won't mind if they are getting portable
> address space.  Network managers currently using stable, well-tested
> solutions like NAT may make for a hard sell unless specific
> advantages can be presented to justify the expense of an upgrade.
> There is also the concern about paying a (possibly increasing)
> address fee for all the machines that were previously behind the
> NAT: even though the IPv6 address space is vast, it's structure
> makes it subject to at least the perception of localized scarcity
> that could be used to justify high prices to end users.  It would be
> unfortunate to switch to IPv6 only to have to switch again to NAT'ed
> IPv6 for cost reasons.

I don't follow the cost argument. What I have seen of the costs of
obtaining v6 addresses is that they are comparable to the lowest  cost
one has to pay to get v4 addresses. However, for that cost one gets
many many more v6 addresses. So the per-address cost of v6 is
significantly lower.

> means a knock-down argument.  I will now return to quietly watching IPv6

Having said all this, I am not claiming that v6 has a strong business
argument over v4 (at this time). It is also not my intention to imply
that your concerns aren't valid (I share the lament). However, I think
we need to be honest about what v6 does today, and what possibilities
it allows for the future. At the same time, I think its also important
that folks be realistic about saying v6 should solve this problem and
at the same time implying that we should just Do It. If someone comes
up with a workable solution, we should have serious discussions about
it. But in the absence of specific, concrete proposals, just saying
"it would be nice" doesn't help and in some cases doesn't adequately
take into consideration that there are real technical reasons why
solutions have not yet been developed.

Thomas

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 07 Sep 1999 17:44:49 -0400

>stable identifier that end hosts can use in place of addresses?

Have two separate identifiers.  One is transient and is used to
indicate the position in the routing hierarchy, and the other is
permanent and can be used to umambiguously identify a host within
the administrative hierarchy.  You also need a way to map from
the permanent identifier to the current transient identifier.

IMHO, IP Addresses, DNS names and the DNS system are adequate
to meet the above three needs.

Margaret

---

From: Ignatios Souvatzis <[email-masked]>
Date: Wed, 8 Sep 1999 10:15:05 +0200

> to meet the above three needs.

Yes.
	-is

-- 
 * Progress (n.): The process through which Usenet has evolved from
   smart people in front of dumb terminals to dumb people in front of
   smart terminals.  -- [email-masked] (obscurity)
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 08 Sep 1999 16:14:30 -0500

> > Have two separate identifiers.  ...  You also need a way to map from

Well, I'll go as far as saying that any claim to the contrary first
needs to show how this trio is *not* sufficient.

			Matt

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 8 Sep 1999 16:06:15 -0700 (PDT)

> the permanent identifier to the current transient identifier.

This sounds very attractive and feasible at the 50,000 foot level.
But the devil is in the details. And since there isn't a fleshed out
proposal for such a system it is impossible to discuss the advantages
and disadvantages.

Even high level "details" like whether or not you can map from
one of the identifiers to the other and vice versa, appear to be open to
discussion among the set of people that have proposed a solution along the
above lines.

   Erik

---

From: Bill Manning <[email-masked]>
Date: Wed, 8 Sep 1999 17:10:49 -0700 (PDT)

> discussion among the set of people that have proposed a solution along the

The NIMROD work of a few years back did explore many details on how
to have independent identifiers. Worked fine as proof of concept.
The papers and detail are still around.

-- 
--bill

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 8 Sep 1999 18:16:54 -0700 (PDT)

> The papers and detail are still around.

Which documents specify this?
RFC 1992 talks about the routing architecture but omits many of
the non-routing aspects of the system. For instance,
 - which mappings exist between the different name spaces (it does mention
   that an endpoint label can be looked up to get both a locator and an EID)
 - how changes to the locators are handled (an endpoint needs to be notified
   both when its own locator changes and when its peer locator changes -
   the security and scalability of such changes need careful study to
   ensure that the system can be made to work in practise).
 - "Security issues are not addressed in this document."

I guess I'm looking for a reasonable detailed *internet* architecture,
as opposed to just routing architecture, that separates the locator and
identifier.

 Erik