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

From: Dan Lanciani <[email-masked]>
Date: Thu, 9 Sep 1999 01:13:41 -0400 (EDT)

Thomas Narten <[email-masked]> wrote:

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

We probably agree about the technical issue but maybe not about motivation.
Clearly wishing to solve the problem is necessary if it is to be solved.  Global
addresses aren't becoming less stable all by themselves.  It is the current
course of our development.  If we wish, we can change that course.  IPv6 was a
chance to start over and it isn't clear that it is optimal to base its
addressing on past implementation restrictions.

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

Well, I see at least two obvious alternatives.

-We develop a distributed routing model that handles portable user addresses
directly.  It is possible to imagine cached route table models that don't
have all the answers all the time.  Things do not have to work in exactly
the way they work today.

-We decide that low-level routing absolutely requires a strictly hierarchical
(and non-portable) address to function efficiently and thus we introduce
another level of portable identifier somewhere between addresses and names.

While neither of these are new concepts, either likely represents too radical
a departure to happen at this late stage.  I suspect that the actual course of
events will involve incremental improvements to DDNS until the situation becomes
palatable enough to accept.  There are a couple of downsides to this.  First,
it's often harder to retrofit a deployed system than to engineer one from
scratch and the result may not be as seamless as it could be.  Second, it's
simply inconvenient (to the point where it won't happen) to replace all fixed-
length binary addresses with domain names.  In particular, I strongly doubt
we will see tcp protocol control blocks contain DNS names any time soon.  Thus
the session stability issue can't easily be solved by DDNS.

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

Why isn't it?  It seems to have become policy that users shouldn't have portable
addresses in _any_ context just because a side effect of a RAM-saving hack under
one routing system of one protocol that equates addresses with routing happened
to result in the current situation.  The leap from the hack to the abstract user
restriction is a big one...

|Routing in the backbone would not be
|able to handle it (i.e., it doesn't scale even today, much less into
|the future).

The scalability issue has always been debatable, even if we are talking only
about brute force implementations of existing models (cf. a recent contributor's
comments about cheap routers capable of managing the IPv4 address space without
aggregation) and it becomes even more nebulous if we consider completely new
models.  However, I'd rather not debate the issue since such a debate usually
involves a framework of difficult-to-define economic assumptions beyond the
purely mathematical notion of scalability.  So I propose to confine further
comments to approaches that preserve hierarchical routing.

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

No.  I wasn't asking for it.  I was pointing out that by failing to provide
such a solution IPv6 will hurt its acceptance, possibly severely.  But sure,
now that you mention it, I'll ask for it. :)

|IPv4 hasn't come up with a solution to this problem and neither has
|IPv6.

IPv4 didn't really need a solution and, in any case, a real solution probably
can't just be glued on to IPv4.  Again, with IPv6 being a fresh start, there
was (is?) a chance to do something at a lower level, or, more generally, to
get some code into the stack before it is widely deployed.

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

Does anybody seriously assert that the problem can't be solved?  The problem
isn't trivial, but I see no (technical) reasons to keep elevating it to such
an untouchable philosophical plane.

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

However, wishing to make it so is a prerequisite to making it so, IMHO.
Do we wish to make it so or not?  If not, why not?  If so, what price
are we willing to pay resource-wise?

|> |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.
|
|But is this problem solvable today?

I think it is, given the motivation.

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

Again, I think you are making the problem far too abstract and untouchable.
Sometimes it's better to have a solution even if it isn't the provably optimal
one rather than to have no solution.  Sometimes even an obviously ugly solution
is better than no solution.  Sometimes the design process gets so hung up in the
metaphysics of the problem that no solution is implemented.  Given that the
Internet will always remain at least in part a research project, I don't believe
that failing to pigeonhole the problem to engineering or research (or even
deciding that it belongs to the latter class) should preclude an attempt at a
solution.  But that's just my opinion.  And I'm starting to repeat myself. :)

|> 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 think this misconception was perpetuated by IPv6 proponents, some of
whom shared it themselves. :(

|I
|don't think anyone who has spent a lot of time working on v6 thinks
|renumbering can be done "almost on a whim".

You don't need to work on IPv6 at all to see this.  It was blatantly obvious
to any technical observer from the beginning that a great deal of work would
be required to back up the hand-waving explanations of painless renumbering.
The problem is that every time the detailed issue was raised there was some new 
reason to table the discussion.  Maybe a modified tcp was just around the
corner.  Or maybe local addresses solve the problem because "nobody" expects
persistent connections outside their own intranet.  The problem is that those
people who have not spent a lot of time working on IPv6 and who are not
technical observers may well still believe what you consider a "fantasy."

|Could you explain a bit more? Why do you think we are giving ISPs
|portable address space?

My belief is based on private mail in response to my original posting in this
thread.  Perhaps the responder would like to elaborate on those plans.

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

Great.  I agree completely.  Let's be honest when trying to sell IPv6.  That
was my whole point.  When making that little IPv4+NAT/whatever vs. IPv6
comparison chart we need to include the downsides.

|There is "hope", but no "promise". Who is making such a
|promise?

Certainly not I. :)

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

That's unfortunate.  I was not aware that the issue had become so inactive.

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

IPv6 addresses are cheap now because they are mostly useless for other than
R&D.  If and when they become commercially useful to end users the price will
increase.  I regularly see ISPs asking for ways to detect NAT activity because
they bemoan the lost revenue they should be making on IP address fees.  One of
the disadvantages (to end users) and advantages (to ISPs) of a collection of
IPv6 addresses vs. an IPv4 address plus NAT is that the ISP will be able to
count and bill for every machine.  Add to that the instability of the internal
addresses when they become IPv6 and I stand by my assertion that the "upgrade"
may be a hard sell.

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

Actually, I think we should just Do It for two reasons.  First, it
will help acceptance.  Second, if and when IPv6 is well deployed
and the issue causes problems, the market will implement a solution
(or worse, multiple incompatible solutions) that may well be (a) worse
kludge(s) than even a far-less-than-optimal approach integrated now.

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

Well, ok, since nobody is working on it, I'll make a proposal.  I don't
guarantee that this is original since I haven't researched other proposals
(though from what you say there aren't many to speak of).  Maybe I'll go
beyond that and say that there likely isn't a shred of an original notion
in the whole thing.  That seems like a good disclaimer...  I'll try to make
it minimally intrusive on existing structure, so it will be a bit of a kludge.
At the same time, it will probably be less of a kludge than even later-term
solutions.

I propose to sever the connection between routing address and identity
address since that's really the only approach that can be glued in at
this late stage.  I propose to create a new address space for identity
and leave the existing one for routing.  To minimize code changes, I
propose that the new address space be the same size as the old.  The
new address space will be allocatable to end users just like IPv4
addresses were in the good old days.  (There's a money-making opportunity
here for a new registry that can sell directly to end users.)

I propose a set of servers, similar in many respects to the DNS but designed to
facilitate efficient and secure dynamic data updates throughout its fabric while
also allowing easy and transparent splitting of zones (i.e., dynamic delegation)
to insure scalability.  The servers will provide a mapping from portable
identity addresses to current routable addresses.  Near the bottom of the IP
layer in each host will exist a mapping layer that uses these servers to convert
portable addresses to routable addresses on packet transmission. (The cache
issues at this level are well understood.)  The portable addresses will be
tucked away in an extension header/option/whatever to be restored on reception
(no inverse lookup will occur).  Most higher layer protocols and APIs will deal
with portable addresses only, e.g., any pseudo-header checksum will be based on
portable addresses, not routable address.  A renumbering of the routable
addresses will have no impact on high-level protocols or applications.  The
mapping layer may also be responsible for updating its routable address in
the mapping server.

Obviously, this approach is a something akin to a cross between ARP and NAT
(though ISPs need not worry--it uses as many routable addresses as portable
addresses, so billing will be unaffected :).  With some attention to detail
it could solve not only the session stability and stable identifier problems
but also provide a pretty close approximation to multi-homing for end-user
sites.  Topologically it is similar to tunneling, but with dynamic setup
giving the effect of a fully-connected matrix.  In fact, you could recast the
implementation in terms of existing tunneling protocols, but this would be
less efficient and would not have the nice property of distributing the
overhead across hosts.

Some random thoughts on this approach:

-There would probably have to be some API escape mechanism for administrative
programs that need to deal with routable addresses.  I believe this could
be done with little impact on the API and no impact on most applications.

-The mapping servers don't have to (and can't easily) provide inverse lookups
to map routable addresses to portable addresses.  In any context where the
host mapping layer is required to perform a lookup, either both addresses or
just the portable address are available.  Only the forward lookup is useful
from a security perspective.  However, to support diagnostic programs we could
allow a query to the host itself for its portable address given its routable
address.

-Isolated and/or transiently connected sites would have a server and/or static
configuration burden similar to that imposed by the DNS.  For true islands,
there's no reason the mapping couldn't simply default to identity.

-Careful gleaning of information from the routable to portable address
relations in incoming packets could minimize lookup traffic, though it
might be tricky to avoid spoofing attacks.  A host should probably do
something pro-active to inform its peers (as known from its map cache)
if its routable address is renumbered to allow reasonable mapping timeouts;
however, mechanisms similar to current stale-route detection could clean up
after glitches.

-If desirable the mapping function could be pushed into a border router.  (I'm
sure something like _that_ has been proposed.)  As another possibility, the
mapping function could stay with the host, but a border router could take
over the job of updating the mapping server em masse since it likely has to
participate in renumbering and may have all the data for the site.  This
could be a big win since individual hosts wouldn't need keys to update the
mapping servers themselves.

-It may be possible, though undesirable, for hosts participating in this
addressing protocol to interoperate with non-participating hosts at the
expense of some address ambiguity.  If we gave up one bit in the current
address (i.e., half the address space) we could make the address type
self-determining, but there's no real advantage in that if this model were
fully deployed.

-This approach presents no additional route table load to the backbone routers
and in fact does not require any support from them at all.  Routers actively
hostile to the protocol could block the header information, but even that could
be overcome with suitable encryption.

-This approach does not require the cooperation of the routable address
administration, though it would be nice to have a little static space to
root the mapping server tree.  Even this isn't necessary since it could
bootstrap from a DNS lookup.  The entire system could be offered by a third-
party much like that funky top-level-domain company, though I think that would
be an unfortunate outcome.

-The main price for portable addresses would be additional header bloat,
much as this was the price for big IPv6 addresses in the first place.  I
consider the value added by portable addresses to be worth the price at
least to the extent that IPv6's bigger addresses were worth the price.  I'm
sure others will disagree.

-The most tricky aspect of the implementation is probably the rendezvous
protocol among the mapping servers in a fluid routing address space.  But
if carefully planned, this protocol can evolve transparently.  (Keep the
part in the host stack simple!)  Any argument that we can't implement such
a system that operates in the face of currently anticipated levels of
renumbering with currently available DDNS-like technology equally means that
we can't support DDNS under IPv6 and that in turn hurts IPv6's case quite a bit.

-One can imagine neat proxy-address hacks to maintain DHCP and dial-on-demand
routable address pools smaller than the total number of portable addresses/nodes
while still permitting outward dynamic connections.  As soon as, say, the PPP
connection is established, the target end node is "renumbered" from the proxy
to an allocated routable address.  This would be useful if/when routable IPv6
addresses become more expensive.

				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: Markku Savela <[email-masked]>
Date: Thu, 9 Sep 1999 10:57:31 +0300 (EET DST)

I changed the subject from "AN interesting article. FYI... contd".

> |identifiers. This can't be just wished away.

I'm just wondering if Mobile-IP architecture would bring some
solutions for this problem?

 - I assume there are at least some organizations or entities that can
   have fairly permanent globally routable addresses (phone companies
   could run home agent service for phonenumbers mapped as IPv6
   addresses, for example)

Based on this, couldn't there be a new class of service: "address
hosting". An organization with globally routable IPv6 address block
would run Mobile IP home agent service for the addressess and would
register them to clients.

Such client could then sign on with any ISP as mobile host, the ISPs
dynamically allocated address would just be the care address. Assuming
mobile-ip6 would be present on ipv6 stacks, and that the assigned
"care address" is fairly permanent, the home agent would be needed
only at connection setup. The ISP's don't need to do anything special
to support this (other than allowing true end-to-end IP connections,
get rid of the pesky NATs!)

Additionally, the client could always use the care address explicitly
for short term connections (like web browsing etc).

One thing though: it should be possible to have "home agent" for a
network. I'm not sure this is possible with current Mobile-ip, the
documents always use examples of single host.

-- 
Markku Savela ([email-masked]), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/
--------------------------------------------------------------------
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: Robert Honore <[email-masked]>
Date: Thu, 9 Sep 1999 09:02:24 -0400

Dear Dan,

> addresses when they become IPv6 and I stand by my assertion that the "upgrade"

I dare say that any ISP who does this is acting very unethically.  The end user
or end-site is only purchasing one thing from his ISP, and that is
**bandwidth**.  Why ought the ISP to care how many IP addresses the end-user has
moving traffic over the link purchased from the ISP?  The bandwidth is what the
ISP sold to the end-user.  The ISP should not charge for anything other than
what is used.

Yours sincerely,
Robert Honore.

---

From: Ignatios Souvatzis <[email-masked]>
Date: Thu, 9 Sep 1999 15:12:44 +0200

> ISP sold to the end-user.  The ISP should not charge for anything other than

and routing and DNS entries. Don't forget that.

	-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: Grenville Armitage <[email-masked]>
Date: Thu, 09 Sep 1999 09:20:51 -0400

Dan Lanciani wrote:
	[..]
>  I regularly see ISPs asking for ways to detect NAT activity because
> they bemoan the lost revenue they should be making on IP address fees.

What a depressing notion. "My oh my, the users are learning to
multiplex! Must figure out a way to stop this...."  Sounds
like the early reputed telco reaction to digital links ("Darn, the
user will be able to fit N phone connections onto this neat digital
link, I need to price it at >= N*cost_of_phone_links just in case that's
what they try using it for..")

gja

---

From: [email-masked] (Niels Möller)
Date: 09 Sep 1999 17:28:10 +0200

Hi,

I've been lurking on this list for a while. I think your concerns are
important (and touches things like tcp-stability, multihoming,
mobility, which I have seen discussed here earlier). 

Dan Lanciani <[email-masked]> writes:

> Well, ok, since nobody is working on it, I'll make a proposal. I
> don't guarantee that this is original since I haven't researched
> other proposals (though from what you say there aren't many to speak
> of). Maybe I'll go beyond that and say that there likely isn't a
> shred of an original notion in the whole thing. That seems like a
> good disclaimer... I'll try to make it minimally intrusive on
> existing structure, so it will be a bit of a kludge.

If you want to look deeper into these issues, I think that is
excellent. I would also like to see some pointers (or even better, a
survey) of previous work in this area.

> here for a new registry that can sell directly to end users.)

Is there any particular reason why not allocate the identifiers as a
subspace of the IPv6 address spase (outside of the aggregatable
unicast space, of course)? I imagine that would make gradual
deployment easier; to a host that doesn't know how to map identifier
addresses, those addresses will simply appear to be unreachable. (It's
even conceivable to let the local router do the mapping and
source-route them to the right aggregatable address).

> I propose a set of servers, similar in many respects to the DNS but
> designed to facilitate efficient and secure dynamic data updates
> throughout its fabric while also allowing easy and transparent
> splitting of zones (i.e., dynamic delegation) to insure scalability.

I suspect this is the difficult part of it all. You need some sort of
hierarchy in order to distribute management and allocation of the
"identity addresses", where higher nodes delegates part of the space
to lower nodes, just like in DNS. And there are some other interesting
points comparing this to DNS:

1. Switching "identity provider" is analogous to switching DNS
   provider. I.e. it implies that your identity or FQDN changes, as
   the point where it is attached in the delegation hierarchy changes.

2. Currently, DNS-space is not much of a hierarchy. It seems all
   "sites" buy a name of the type "foo.com.", and put all externally
   visible machines there. Really large sites or corporations may have
   one more step of internal delegation. The point is, that this
   appears to actually work. So perhaps it's good enough to have a flat
   identity space, or at most two-level space?

Another question is exactly what advantage the short "binary"
addresses have over dns names. You say that they fit easier into
packet headers, tcp control blocks, etc. If that is the main reason to
use them rather than FQDN:s, perhaps we could get away with
representing a FQDN with its md5 sum, and we will have at least one
step in the lookup process for free. Or if that won't work, I think
the reason why may give some information about the nature of the
problem.

Hmm. Anyway, I don't think this problem will be solved by me or
anybody else popping ideas from their head. Someone has to figure out
the evil little details, propose a solution, and then we can discuss
that.

If you can do that, I think that is a very valuable contribution. 

/Niels

---

From: Thomas Narten <[email-masked]>
Date: Fri, 10 Sep 1999 10:42:49 -0400

Dan,

A few comments.  Unfortunatley, I don't have the time right now to
respond to all of your proposal in detail, but I will observe that
there are a number of details missing. Unfortunately, the devil is in
the details and without the details, its hard to call out specific
issues. This has been one of recurring problems with discussing and
analyzing alternate architectures -- it's easy to imagine a system
working if one hand-waves some of the details.  Yet, those details are
often critical and important.

Also, you raise an oft-expressed feeling that all that needs to happen
is for some folks to go off and design such a system. At one level,
that is correct. However, there have been a number of such attempts in
the past, with unfortunately, the details/results mostly discussed in
hallways and on various mailing lists (e.g., big-internet list).  A
number of the specific things you propose have a familiar ring. If you
haven't done so already, I'd encourage you to have a look in the
following places:

 - draft-ietf-ipngwg-esd-analysis-04.txt and Mike O'Dell's expired ID
   that this draft considers (available at
   ftp://munnari.oz.au/gseaddr-00.txt). The detailed meeting minutes
   from the february 1997 ipng meeting where the proposal was
   discussed in detail are also useful reading:
   http://playground.sun.com/ipng/minutes/ipng-minutes-feb97.txt

 - browse the big-internet archive at ftp://munnari.oz.au/big-internet

Also, I don't think it is entirely a question of whether such a system
can be built. No doubt it can. The relevant question is whether in the
end we'd have a system that is implementable, deployable, and scalable
to an internet with billions of nodes. And, (and this is _key_) would
the resultant system be any better than what we already have in terms
of total overall cost, understandabilty, robustness, operational
complexity, etc?  I often think that one of curses of IPv4 is that
both its strengths and weaknesses are well understood. People tend to
focus on the weaknesses (e.g., non-portable addresses) and
consequently the grass looks greener on the other side of the hill. It
also appears, however, that the alternate proposals don't really make
the renumbering/portability issue go away, they just move a hard
problem somewhere else, where it is not necessarly recognized as being
a hard problem (at first) and hand-waved as solvable. Here again is
where details are needed. One needs to understand what has been
shifted elsewhere, and whether the new/shifted problem is any easier
to solve.

Case in point: if we separate the identifier and locator portions of
an address, one almost certainly needs a way of mapping the identifier
into an locator. This problem is one that we don't know if it can be
reasonably solved without seeing the details of a specific
proposal. Just saying "servers do the mapping" is hand waving.

> Why isn't it?  It seems to have become policy that users shouldn't
> have portable addresses in _any_ context just because a side effect
> of a RAM-saving hack under one routing system of one protocol that
> equates addresses with routing happened to result in the current
> situation.  The leap from the hack to the abstract user restriction
> is a big one...

It is an enduring myth that backbone routing can scale arbitrarily and
that the only issue is an implementation defficiency from one vendor
(which has long since been fixed). The size of the forwarding tables
that routers need to maintain is not the only (or even most important)
issue. The issues is scalability of the routing computations that (as
an end result) produce the forwarding table that routers use to
actually forward packets. The cost of the calculation is dependent on
the number of factors, including the number of routing prefixes one
has to deal with, the number of peers a router is exchanging
information with, plus the size/complexity of the policy database that
BGP uses to shape its routing calculation, the frequency of updates
(e.g., one can increase the number of routes one can deal with by
slowing convergence time so that routing tables aren't required to
react to routing changes quickly -- something many folks wouldn't
react positively to), etc.

The folks actually responsible for keeping routing working in the
default free zones of the backbones are the ones that have pointed out
these issues.

> Again, I think you are making the problem far too abstract and
> untouchable.  Sometimes it's better to have a solution even if it
> isn't the provably optimal one rather than to have no solution.
> Sometimes even an obviously ugly solution is better than no
> solution.  Sometimes the design process gets so hung up in the
> metaphysics of the problem that no solution is implemented.  Given
> that the Internet will always remain at least in part a research
> project, I don't believe that failing to pigeonhole the problem to
> engineering or research (or even deciding that it belongs to the
> latter class) should preclude an attempt at a solution.  But that's
> just my opinion.  And I'm starting to repeat myself. :)

The reason I make the distinction between engineering and research is
that the IETF is good at making engineering tradeoffs, and it also
means the issues are well enough understood that its something we can
likely build and deploy -- we just need to work through the details.
If it's _research_, however, we have much less confidence that
something can be built and deployed. The Internet is long past being a
research toy. Before betting the future internet on a new
architecture, we need to have confidence that it can be deployed and
will work. The problem with "a solution ... even if not optimal", is
that we may find that it doesn't work/scale once deployed and may not
actually be any better than what we already have. That is not the kind
of gamble I think we can make when we're talking about basic
infrastructure. Hence, we need to work through the details first.

Perhaps followups (on specific proposals) should go to
[email-masked]? There are likely a number of folks on that
list that have an interest in this topic that do not subscribe to the
ipng list.

Thomas

---

From: Quality Quorum <[email-masked]>
Date: Fri, 10 Sep 1999 14:28:05 -0400 (EDT)

Hi,

I have simple Joe-six-pack question about renumbering.

If I have IP session (TCP or UDP) and renumbering event happen on
either end of the connection, then I suppose that my connection will 
not survive. It does not seem like a big deal if session reestablishment 
will be transparently handled by a protocol stack, however, it seems like 
it is not the case, moreover, it seems like say UPD client has no 
way to figure out that UDP server experienced renumbering events, am
I correct about it ?

Thanks,

Aleksey

---

From: Francis Dupont <[email-masked]>
Date: Sat, 11 Sep 1999 17:27:03 +0200

In your previous mail you wrote:

=> I believe your idea is: a home ISP gives (home) addresses which
are more stable than current (care-of) addresses?
There are some issues:
 - home agents must be "in" the home prefix then the problem is still
   the same even you can expect far better stability for the virtual
   home ISP.
 - before bindings and/or with correspondents which don't manage bindings
   the traffic to you will go through the home agent which is expensive
   (these two points show a good solution should not use home agents)
 - even with bindings there is an overhead then this kind of solutions
   should not be permanent.

=> there is only one case where permanent globally routable addresses
are very important: root DNS servers.

=> your idea seems to be the virtual home ISP, isn't it?

=> in any case bindings should be used for multihoming purposes only
for long term connections because of the overhead and the need for
authentication.

=> you can have a home agent (or a set) for each individual nodes in
a network.

Regards

[email-masked]

PS: you should read my I-D about another usage of mobility "bindings"
for multi-homing in a very light way (without home agents for instance).
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Sat, 11 Sep 1999 17:45:42 +0200

not survive.

=> it should be the case only when the old address becomes invalid:
when a site is renumbered a new prefix is used and the old one is
first deprecated, then invalided and at the end removed. You can
stay in the intermediate/deprecated state for typically a month (*)
then renumbering is an issue only for sessions with a lifetime longer
than a renumbering period.

Regards

[email-masked]

PS (*): a deprecated address is not used by definition for new connections
then the only good reason to make it invalid (and to garbage collect very
long term connections which are still using it) is because the prefix
will be reused. This gives delays in months both in IPv6 specs (RFC 2461
has 7 and 30 days for AdvPreferredLifetime and AdvValidLifetime) and
in regional NIC documents as ripe-196 (at least 12 months to return
the sub-TLA space).
--------------------------------------------------------------------
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: Markku Savela <[email-masked]>
Date: Mon, 13 Sep 1999 11:48:15 +0300 (EET DST)

> From: Francis Dupont <[email-masked]>

Yes, in part. As an impelementor I was worried about overlapping
solutions. But, from your draft-ietf-ngtrans-6bone-multi-01.txt I see
that things appear to go into right direction. Seems that mobile IP
can be seen as levels

Level 1 (simple address change) 
 - home address option (or Level 0)
 - binding requests directly between corresponging nodes

Level 2 (mobility)
 - home agent functionality

> => your idea seems to be the virtual home ISP, isn't it?

I suppose, I wish every one should have a right to addressable
identity on the network without any cost (you don't pay for you name
now, why should one pay for network identity). "Virtual home ISP"
might be one way, but who would run such things is another
matter. Technical problems are minor compared to all possible privacy
issues, spam or abuse of such system.