Subject: [RRG] Consensus? End-user networks need their own portable address space

From: Robin Whittle <[email-masked]>
Date: Sun, 25 May 2008 19:35:15 +1000

Can we form rough consensus on this?

Short version:

  End-user networks need their own portable address space.

Long version:

  A primary requirement of any solution to the routing scaling
  problem is to provide a new mechanism by which end-user networks
  (however defined, potentially those of corporations and
  universities, but also down to home-office networks or perhaps
  a single mobile host's network) can change their ISP without
  significant impediment, including especially the current barrier
  formed by the need to renumber their entire network, if their
  current address space is PA (Provider Assigned).

  There are two solutions to this:

  1 - They use non-portable PA address space, including perhaps
      two or more prefixes of PA space for the purposes of
      multihoming.  In order to achieve this in a way which
      sufficiently minimises costs and disruption, the following
      would need to be true:

      The end-user networks would need to be constructed of
      hardware, software and to use protocols such that the entire
      network and all its hosts, routers etc. can be made to operate
      from a different prefix with minimal disruption.  (Perhaps not
      devices which are only accessed internally, such as printers.)

      In order for this to be the case, a very large number of
      settings inside routers and hosts would need to be changed
      automatically, with great reliability, in response to a single
      securely authenticated, system-wide re-addressing command.

      Despite the provisions within IPv6 for automatic address
      assignment, with continued connectivity while changing from
      one prefix to another, current networks are far from being
      structured along these lines - and there is no prospect of
      this changing in the timeframe within which we need to solve
      the routing scaling problem.

      The first reason is that almost all current networks are
      IPv4 networks - and as I argue in another message, we need to
      directly solve the IPv4 routing scaling problem.

      The second reason is that IPv6 addressing automation does not
      reliably and securely cover all locations where an IP address
      is specified.  For instance, as far as I know, it doesn't
      apply to DNS zone files, or to router ACLs, or to the config
      files of things like IMAP servers about which addresses they
      respond to.  At the very least, any such automation would
      require secure rewriting of parts of text files, and secure
      restarting of the server, application etc. - all under
      centralised control of the system administrator.

      There are no realistic prospects for developing such a
      wide-ranging architecture for finding all such config files
      and securely changing them.

      In summary, this is impossible for both IPv4 and IPv6
      networks at present.  It will remain impossible for the
      foreseeable future - any 5, 10, 15 year timeframe in which the
      RRG  solution needs to work. (I guess we want a fix which
      actually works by 2013 or so.)

  2 - Portability of address space.

      There are changes to the routing and addressing system which
      enable end-users to keep their address space no matter which
      ISP or multiple ISPs they use - in a way which does not
      add to the routing scaling problem.

      Assuming the new arrangements perform well, this is providing
      end-users with exactly what they want and need.

      LISP, APT, Ivip and TRRP all provide this, although there
      remain some dependencies in terms of who the address space
      is obtained from.

   - Robin       http://www.firstpr.com.au/ip/ivip/

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Randall Atkinson <[email-masked]>
Date: Sun, 25 May 2008 04:55:13 -0700

Earlier, Robin wrote:
%  End-user networks need their own portable address space.

Users care greatly about capabilities (e.g. ability to multi-home
for improved resilience/availability, ability to change the set of
contracted upstream providers to reduce communications costs,
traffic engineering, mobility).

Users do NOT generally believe they want or need "portable
address space" -- except as an engineering mechanism to
achieve the other higher-level capabilities.

So if there are alternative architectures that provide those
capabilities without requiring "portable address space",
then users will not *care* whether they have "portable
address space" or not (provided they can have the
capabilities in some other way).

Users care about capabilities, not the engineering mechanism.

Discussions here are indicating that there are several
different ways to provide those desirable user capabilities
-- and also that some of those approaches do NOT require
"portable address space".

So I don't think your consensus claim here is reasonable,
given the set of architectural options available to the RG.

Cheers,

Ran
[email-masked]

---

From: Robin Whittle <[email-masked]>
Date: Sun, 25 May 2008 23:14:26 +1000

Hi Randall,

> traffic engineering, mobility).

Sure.

> achieve the other higher-level capabilities.

OK - but there is no other engineering mechanism than portable
address space which enables them to switch to another ISP without
unreasonable costs and disruption.

> capabilities in some other way).

Sure, but there are no other alternatives.

> "portable address space".

What mechanisms other than portable address space are there which
would enable any decent sized network to change ISPs without a great
deal of error-prone manual work?

> given the set of architectural options available to the RG.

Can you cite an example of techniques in use today which make any
end-user network easy to change from one PA prefix to another?  I
wrote about how IP addresses turn up in config files for IMAP
servers, but they also turn up in web servers, in DNS zone files,
and in all sorts of other servers.  If the network includes a bunch
of printers and other IP-enabled devices which don't work on some
private address range, they will need to be identified and their
configuration altered too.

I wrote a specific argument about why I think there is no prospect
of there being reliable automated system for changing all this stuff
for most end-user networks.  If you think there is one, or that
there will be one, then please provide specifics.

  - Robin

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 25 May 2008 15:05:26 -0400

>  End-user networks need their own portable address space.

s/End/Some end/

To be pedantic about it, there will be for our lifetimes and beyond  
enduser networks
happy to accept whatever solution their ISP provides, as long as it  
works.
But, of the ones that want it, some will want it badly enough they  
will get it
one way or the other.

Other than that, +1 from me.

The elephant in the room here, of course, is NAT, which is the  
"solution 0" here.

Regards
Marshall

---

From: "Tony Li" <[email-masked]>
Date: Sun, 25 May 2008 12:56:34 -0700

|> Can we form rough consensus on this?
|>
|> Short version:
|>
|>  End-user networks need their own portable address space.
|
|s/End/Some end/
|
|To be pedantic about it, there will be for our lifetimes and beyond  
|enduser networks
|happy to accept whatever solution their ISP provides, as long as it  
|works.
|But, of the ones that want it, some will want it badly enough they  
|will get it
|one way or the other.
|
|Other than that, +1 from me.

I would say that end some end-user networks _want_ their own portable
address space.  

If we provide solutions that give end-users the functionality without that
particular mechanism, I can't rationally say that there is a _need_.

Tony

---

From: Randall Atkinson <[email-masked]>
Date: Sun, 25 May 2008 14:01:18 -0700

% OK - but there is no other engineering mechanism than portable
% address space which enables them to switch to another ISP
% without unreasonable costs and disruption.

Several approaches that provide those capabilities have been
discussed here in the past.  So I disagree with "there is no
other ... mechanism".

% Sure, but there are no other alternatives.

I disagree that "there are no other alternatives".

% What mechanisms other than portable address space
% are there which would enable any decent sized network
% to change ISPs without a great deal of error-prone
% manual work?

One can imagine several methods.

Decoupling the TCP session state from the IP address(es) in use,
which was one possibility envisioned at the IAB Workshop,
enables a range of different approaches, for example.

% Can you cite an example of techniques in use today which
% make any end-user network easy to change from one
% PA prefix to another?

Again, your premise is wrong.  The Routing RG can consider
any architectural approach -- whether or not that proposed
approach is "in use today".

Yours,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 May 2008 14:12:21 +1200

> particular mechanism, I can't rationally say that there is a _need_.

Exactly. IPv6 was designed to remove the _need_, although there's no
doubt that most IT departments around the world haven't understood
this. Unfortunately IPv4 prefix assignments, both pre-CIDR and since
the registries folded by starting to make PI assignments, have led to
established practice that IPv4 prefixes are viewed as property. It's
too late to change that for IPv4, but we shouldn't confuse that
contingent fact with architecture.

   Brian

---

From: Robin Whittle <[email-masked]>
Date: Mon, 26 May 2008 13:38:56 +1000

I am replying to Tony, Randall and Brian.

> particular mechanism, I can't rationally say that there is a _need_.

The point of my argument is that the only possible mechanism is
portability.

This is a well-known, decades old, problem.  The best
non-portability solution anyone has suggested or developed is the
automatic renumbering stuff in IPv6.  This is impressive looking,
but I doubt it has been widely road-tested in real, large, networks
- because few, if any, such networks use IPv6.

As I argued in my original message, even if it works as advertised,
it does not go nearly far enough to meet the real needs for
seamless, reliable, changeover from one ISP to another.

Besides, there is no such auto-renumbering arrangement for IPv4 -
which is where the Internet's routing scaling limitations are a
genuine problem.

I don't think it is reasonable at this late stage in the RRG process
to avoid the conclusion that portability is the only way of giving
end-users what they need in terms of freedom of choice of provider.

> enables a range of different approaches, for example.

This would involve host changes and would only work for TCP - so
this is not a solution at all.

It wouldn't help with the need for a network changing from one PA
prefix to another to change IP addresses in server config files, IP
addresses in zone files, in ACLs etc.

> approach is "in use today".

Sure.  We have had a year or so for people to propose a solution
other than portability.

So far, no such solution has emerged.

We need to start refining goals, and I believe we should cut out all
this stuff about pretending end-user networks should be happy with
PA space, and recognise that in order to meet the goals set by RAWS
- seamless, reliable, low-cost ease of change of provider (my
paraphrase) - we need to provide a new form of address space which
is portable without adding to the routing scaling problem.

Brian E Carpenter wrote:

> Exactly. IPv6 was designed to remove the _need_, although there's
> no doubt that most IT departments around the world haven't
> understood this.

My guess is that IT departments do not think that IPv6's automated
procedures solve all the problems they face in adopting a new PA
prefix.  Also, they are concerned about IPv4, not IPv6.

> Unfortunately IPv4 prefix assignments, both pre-CIDR and since
> the registries folded by starting to make PI assignments, have led
> to established practice that IPv4 prefixes are viewed as property.

This is unfortunate from the perspective of someone who wants to
ensure that end-users never retain the address space they used with
one ISP when they move to another.

It is fortunate and necessary for all those end-user networks who
have been lucky enough to get PI space.

The two problems we need to solve are closely related:

  1 - Not enough end-user networks can get this PI space.  (The
      map-encap proposals aspire to scale to hundreds of millions
      or billions of such end-user networks.)

  2 - Even the number that do get PI space causes an unacceptable
      burden on DFZ router operators - the routing scaling problem.

Since no-one has a solution other than portability, I believe the
only way we can solve the routing scaling problem while meeting the
goal of reducing provider lock-in is to recognise this and provide
portability to end-user networks of all sizes - from large
corporations to home-office and perhaps cell-phone users.

> It's too late to change that for IPv4, but we shouldn't confuse
> that contingent fact with architecture.

I would appreciate it if you all addressed my detailed argument that
there is no other method than portability of enabling end-user
networks to change providers without giving them portable PI space.

One of the major purposes of all the map-encap schemes (Six/One
Router too?) is that the new kind of space they provide is fully
portable, without burdening the DFZ routing table.  The most fully
developed attempts to meet the RRG's tasks all provide portability -
and I think the objection to portability stems in large part from
the current situation where each portable prefix adds to the routing
scaling problem.

  - Robin

---

From: "Tony Li" <[email-masked]>
Date: Mon, 26 May 2008 00:36:32 -0700

|The point of my argument is that the only possible mechanism is
|portability.

Provably incorrect: many organizations are very happy sitting behind a NAT
box.  It provides excellent addressing isolation.

Tony

---

From: "William Herrin" <[email-masked]>
Date: Mon, 26 May 2008 21:07:50 -0400

>  End-user networks need their own portable address space.

Concur but I want to explicitly state the assumption:

[In any complex internet in which the host network address is not
strictly ephemeral,] end-user networks need their own portable address
space.

In theory, we could redesign IP from the ground up so that the
hostname was king and the network addresses assigned to a particular
machine could change at any time without disrupting communications. In
practice, we're not going to and if we were going to it would be far
beyond the scope of this working group. This leaves us at your
conclusion.

> achieve the other higher-level capabilities.

Users care about capabilities. The only engineering mechanism which
has ever been found that implements the capabilities you listed to the
consistent satisfaction of the users is providing them with their own
portable address space.

If A=B and B=C then A=C.

I'm dealing with this at work now, getting ready to dump yet another
/24 into the core because it's not practical for the one-way
transmitters sending the system data packets to determine where the
listener currently is.

I'll tell you straight up: if you build a new system that can't scale
to deliver portable addresses to all the end users that want them,
you're just wasting everybody's time. Do yourself a favor and treat it
as a requirement, whether you believe it will turn out to be or not.

On Sun, May 25, 2008 at 10:12 PM, Brian E Carpenter
<[email-masked]> wrote:
> this.

Yes, it was indeed an IPv6 design goal. As discussed on essentially
all of the RIR policy lists, that missed goal has been one of IPv6's
more egregious failures. It's not that the IT departments don't
understand, its that regardless of its goals, IPv6 just doesn't
accomplish that job, not even in an ideal world.

This is not the proper forum, so I'll leave it there but if you really
want to hear the litany of why IPv6 makes the demand for PI space
worse instead of better, feel free to contact me offlist.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked] [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Randall Atkinson <[email-masked]>
Date: Mon, 26 May 2008 18:47:42 -0700

Earlier Bill Herrin wrote:
% In theory, we could redesign IP from the ground up so that the
% hostname was king and the network addresses assigned to a
% particular machine could change at any time without disrupting
% communications. In practice, we're not going to and if we
% were going to it would be far beyond the scope of this working
% group. This leaves us at your conclusion.

There are various practical ways to make it possible to change
a node's IP address(es) without disrupting communications.

SCTP is deployed, standardised existence proof that this can be
done in the current Internet.  So far from there being only one
workable approach, we have a proof there are multiple approaches
that could be undertaken.

For TCP & UDP a range of approaches exist, including one
(which I think Mark Handley has proposed here) that is very
similar to what SCTP already uses for address agility.

O'Dell's GSE work shows this also can be done in other,
different ways.

As to the RG charter, my understanding is that changes
such as the ones I've outlined above are within the scope
of the RG.

(Of course, only the chairs' can clarify this officially; your view
of the RG charter -- and mine -- are just personal opinions.)

% Users care about capabilities. The only engineering mechanism
% which has ever been found that implements the capabilities
% you listed to the consistent satisfaction of the users is providing
% them with their own portable address space.

Again, SCTP is a deployed existence proof that other mechanisms
than portable address space do exist in the deployed Internet.

Cheers,

Ran
[email-masked]

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 27 May 2008 01:21:35 -0700

> box.  It provides excellent addressing isolation.

hmm, aren't addresses behind a NAT box portable addresses?

Lixia

---

From: "William Herrin" <[email-masked]>
Date: Tue, 27 May 2008 18:44:37 -0400

> a node's IP address(es) without disrupting communications.

Sure. And I have a really clever one that dynamically carries IP
address assignment and reassignment with the routing protocol so that
you get as near as possible to perfect aggregation in the routing
system and "IP address manager" ceases to be a paying job. 20k FIB
coexists with multihoming for the masses. Dead serious by the way.

The hitch is, it requires that all applications abandon the TCP and
UDP protocols and APIs, in favor of an API where the app requests
communication by name instead of by address and lets the host keep
track of which addresses currently associate with that name. The
network addresses become strictly ephemeral. Not only can they change
regularly, they do change regularly as a result of reassignment due to
the changing demand for addresses in the nearby portions of the
network.

I'm sure, of course, that Internet will abandon address-based UDP and
TCP sometime after hell freezes over. We might possibly do it before
pigs fly.

Regards,
Bill Herrin

---

From: "Tony Li" <[email-masked]>
Date: Wed, 28 May 2008 00:51:44 -0700

|> |The point of my argument is that the only possible mechanism is
|> |portability.
|>
|>
|> Provably incorrect: many organizations are very happy 
|sitting behind  
|> a NAT
|> box.  It provides excellent addressing isolation.
|
|hmm, aren't addresses behind a NAT box portable addresses?

No, they're usually private (RFC 1918) addresses.

Tony

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 18 Jun 2008 22:18:21 -0700

apology for this belated reply. My spring teaching finally came to an  
end, hope I have more time to catch up RRG now

> No, they're usually private (RFC 1918) addresses.

my interpretation of "portable", or not, is by the measure of whether  
one needs to renumber when changing providers.
By this definition, 1918 addresses are indeed "portable"

someone explained to me privately that Robin's definition of  
"portable" is equivalent to PI prefixes.

To me a PI prefix has 2 separable meanings: globally uniqueness, and  
portability.

Lixia

---

From: Robin Whittle <[email-masked]>
Date: Thu, 19 Jun 2008 18:05:41 +1000

Hi Lixia,

> To me a PI prefix has 2 separable meanings: globally uniqueness, and

I tried to give a short version in my original message:

  http://psg.com/lists/rrg/2008/msg01310.html

In the context of this discussion, it is assumed the space is globally
reachable - and "their own" implies the address space is globally unique.

The rest of my message beyond the short version leaves no room for doubt about
what I was suggesting.

I was discussing the solution to the need to be able to change to another ISP
without excessive risk, cost or disruption - where that solution would be
available in the time-frame I assumed the RRG was working within.

I assumed we would be making an architectural enhancement to to the current
architectures - IPv4 and then IPv6 - and so I assumed the RRG would propose a
solution to be implemented in the next 5 to 7 years.  This would mean choosing
an approach to this problem soon.  In all the years of fussing over this
problem, no solution other than portable PI space has ever been practical, and
I think it would be unrealistic to expect that a new, non-portable solution,
will turn up in the next 9 months in a substantial enough form that we could
recommend with confidence that it e applied to the Internet.

Based on my original assumptions about time-frame and IPv4, here is a more
explicit form of the short version:

  http://psg.com/lists/rrg/2008/msg01310.html

    In the timeframe available - choosing a technique by 2009-03 to
    recommend for development and then IPv4 deployment in 2012-15 -
    there is only one approach we can consider for enabling end-user
    networks to change providers without excessive risk, cost or
    disruption:

      A new form of address space which resembles current PI space
      in that it is entirely portable, unique, public and reliably reachable,
      but which is provided in a scalable way, to avoid the well
      known problems which each PI prefix causes today.

All the map-encap schemes can do this, so it is not an unrealistic requirement.

Rough consensus has been achieved that the RRG-suggested solution need not
apply to IPv4.  In that case, perhaps the time-scale for the RRG solution
being developed and applied may be much longer than I originally assumed.  In
that case many more options become available, since IPv6 has more scope for
being altered to support solutions other than map-encap, and since I think an
IPv6 solution is less urgent.

I think that before much else can be decided, it would be good to decide
whether or not an RRG solution will be developed for IPv4 (this has not yet
been ruled out) and what the time-frame is for developing and deploying the
solution(s).

With a longer time-frame and if the RRG is to seriously contemplate a
GSE-style radical revision of IPv6, perhaps some people may suggest solutions
for the changing ISP problem which are not so clearly "portable".

However, I still think that portable (and public, unique, globally reachable)
space always will be absolutely required, for IPv6 or IPv4, since there will
never be a situation where a complex network can be automatically changed to
use another prefix without excessive costs, risks and disruption.  As long as
we have packets and routers, there will be IP addresses controlling the fate
of packets, and those IP addresses will turn up in raw form (not a FQDN) in
routers, DNS zone files, server config files etc.

BTW, can you or anyone else point me to the "Handley Proposal"?

  - Robin

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 19 Jun 2008 07:48:47 -0700

> reachable - and "their own" implies the address space is globally  

Robin, thanks for your long and detailed reply (I wish I could write  
that fast:)

I tend to identify separable issues. We agree that a PI prefix really  
means 2 things, and portability is only one of the two.  That's all my  
msg last night intends to clarify.

I agree with you too that RRG aims at an architectural solution to  
routing scalability problem, the topic pursued on another ongoing thread

> .....

look for the msg Mark sent to RRG
   Date: February 18, 2008 9:35:09 PM PST
   Subject: [RRG] Are we solving the wrong problem?

Lixia

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jun 2008 10:05:16 +1200

On 2008-06-19 17:18, Lixia Zhang wrote:
> someone explained to me privately that Robin's definition of "portable"
> is equivalent to PI prefixes.
> 

In any case, it seems to be a solution, not a requirement.

    Brian

---

From: "William Herrin" <[email-masked]>
Date: Thu, 19 Jun 2008 22:44:44 -0400

> In any case, it seems to be a solution, not a requirement.

Brian,

Yes and no.

The requirement is that end users (meaning folks who operate servers
in this case) be able to  change service providers:

1. Without a major overall effort, and
2. Without requiring any changes outside of the end user's
administrative control.

In the past two decades, NO ONE has demonstrated a mechanism for
meeting these two requirements that has proven out in practice EXCEPT
for assigning PI addresses to the end user. Quite the contrary: the
past decade has shown a dramatic increase in strangers filtering data
by source IP address, busting the heck out of requirement 2.

Under the circumstances, it is appropriate to escalate the solution
(PI addresses) to requirement status. If at some point in the future
someone demonstrates an workable architecture which unequivocally
meets the original two requirements, we can just as easily reverse the
escalation. Given the history, the onus should be entirely on the
newcomer to demonstrate that they really have an in-practice workable
solution that doesn't require PI.

Regards,
Bill Herrin

---

From: "Tony Li" <[email-masked]>
Date: Thu, 19 Jun 2008 21:52:21 -0700

Hi Bill,

|The requirement is that end users (meaning folks who operate servers
|in this case) be able to  change service providers:
|
|1. Without a major overall effort, and
|2. Without requiring any changes outside of the end user's
|administrative control.
|
|In the past two decades, NO ONE has demonstrated a mechanism for
|meeting these two requirements that has proven out in practice EXCEPT
|for assigning PI addresses to the end user.

False.  Put the site behind a NAT box.

Changing providers now simply requires a trivial change to the NAT.

Tony

---

From: "William Herrin" <[email-masked]>
Date: Fri, 20 Jun 2008 08:55:09 -0400

> Changing providers now simply requires a trivial change to the NAT.

Tony,

Placing your mail server behind a NAT box and changing the NAT IP
during a move does absolutely nothing to update the public and private
RBLs and whitelists.

Placing your VPN concentrator behind a NAT box and changing the NAT IP
during a move does absolutely nothing to update the customer IPSec VPN
clients which connect to it.

Placing your customer web servers behind a NAT box and changing the
NAT IP during a move does absolutely nothing to update the
customer-controlled DNS domains pointing to it. They can't avoid that
problem up front with CNAMEs to your DNS because they often desire the
same name that holds the NS and SOA records to reach the web site.

Demonstrated: three common configurations which fail to pass criteria
2 despite the introduction of NAT.

Your assertion that NAT resolves the two requirements without PI is
proven incorrect. Nice try, please play again.

Regards,
Bill Herrin

---

From: Scott Brim <[email-masked]>
Date: Fri, 20 Jun 2008 09:35:39 -0400

> 2. Without requiring any changes outside of the end user's

I don't believe the second one.  First there's simple lower layer 
connectivity -- of course you need permission from a NSP if you want to 
receive traffic.  Second there's routing.  I see no way for packets to 
me to traverse an intermediate provider without at least some node under 
that provider's control being configured differently.  If I use IP 
addressing, it has to know that my addresses are reached via a 
particular link, and a responsible NSP will not just believe a route 
some new customer tosses at it.  If someone sending a packet to me 
encapsulates it all the way to a node I control, still the intermediate 
NSP needs to know what link to send the packet on.  If I use connection 
setup of some kind, still there has to be some way for the intermediate 
NSP to know how to reach even just one (representative) node in my 
network. ... so changing your connectivity will always require changes 
by the network you are connecting to.

> solution that doesn't require PI.

PI is a solution, not a requirement.  The requirements are easy 
multihoming and easy connectivity change.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 20 Jun 2008 16:35:31 +0200

> during a move does absolutely nothing to update the public and private

This case probably deserves more elaboration.  Today, just about every 
email reputation system is based on the IP address of the sender.  There 
are many such systems, including RBLs, PBLs, etc.  Legitimate senders 
that originate large volumes of mail do not like this precisely because 
it takes time to develop a positive reputation.  In some cases these 
guys end up either inheriting or even sharing IP addresses through 
common MTAs where their reputations are tied together.

Within the IETF we've developed DKIM that I hope will spawn reputation 
systems based on domain and not IP addresses.  However, that is very 
much a speculative notion, and certainly far in the future.  One reason 
it's speculative is that it may well be that people want to use both IP 
address AND domain to make their processing decisions.  They can make 
the answer on IP address far earlier in an SMTP transaction than they 
can on domain, and that has its advantages.

The key point for this group is simply this: the IP address *is* an 
identifier, an index key, and many other things that we'll never fully 
know.  It is possible to change, but only gradually over time.  If it 
doesn't have to, all the better.

Eliot

---

From: Scott Brim <[email-masked]>
Date: Fri, 20 Jun 2008 10:45:35 -0400

> doesn't have to, all the better.

Whats your conclusion?  That we need to assume the IP address will be 
used as an identifier by higher layers for the foreseeable future, and 
figure out how to live with it?

---

From: Eliot Lear <[email-masked]>
Date: Fri, 20 Jun 2008 16:54:48 +0200

Scott,
> figure out how to live with it?

I am loathe to make a sweeping statement here, but when considering the 
economic incentives for change (or lack thereof), all those lovely uses 
Bill mentioned are economic disincentives from breaking the identifier 
association from an IP address, and economic incentives for PI approaches.

Eliot

---

From: "William Herrin" <[email-masked]>
Date: Fri, 20 Jun 2008 10:59:21 -0400

On Fri, Jun 20, 2008 at 9:35 AM, Scott Brim <[email-masked]> wrote:
> receive traffic.  Second there's routing.  I see no way for packets to me to
> traverse an intermediate provider without at least some node under that
> provider's control being configured differently.

Scott,

Allow me to clarify: the actions of an entity from which you purchase
service are under your administrative control for the purposes of
establishing criteria #2. You're paying them to do as you require.
Arguably this continues upstream following the cash though as a
practical matter you lose control more than a couple orgs away.

Entities which purchase service from you are not under your
administrative control. Entities with whom you have no fiduciary
relationship whatsoever are not under your administrative control.

With that clarified definition of "without requiring any changes
outside of the end user's
administrative control," do you have any further objections to this
requirement? Would you like to rewrite the statement so that its more
clear that one's vendors fall within one's administrative control?

BTW, my counter proof to Tony's claim only addressed single-homed
cases where PI is a necessary consequence of the requirements. Nearly
all multi-vendor multi-homed cases require PI to function to an
appropriate standard as well.

Brian: This argument you see now is a fine example of why it's
appropriate to escalate "PI for servers" to architectural requirement
status. More than a few very smart engineers want NAT to have solved
the need for PI but operational experience in the decade plus since
NAT's invention very clearly show us that it has only solved the need
for PI in a limited set of scenarios.

Movement on the PI requirement since NAT's full deployment has been
largely retrograde: changing the IP address of a high-volume mail
server has become astonishingly hard because of all the spam
filtering, as is corralling the 500 customers all of whom have
forgotten the Godaddy passwords they need to update the A records for
their hosted web service since they do that with Godaddy now instead
of hosting their DNS with you.

We're well past the point where "PI for servers" should be considered
an architectural requirement until proven otherwise.

Regards,
Bill Herrin

---

From: "Tony Li" <[email-masked]>
Date: Fri, 20 Jun 2008 08:39:59 -0700

|> The key point for this group is simply this: the IP address *is* an 
|> identifier, an index key, and many other things that we'll 
|never fully 
|> know.  It is possible to change, but only gradually over 
|time.  If it 
|> doesn't have to, all the better.
|
|Whats your conclusion?  That we need to assume the IP address will be 
|used as an identifier by higher layers for the foreseeable future, and 
|figure out how to live with it?

My conclusion is that if we want to truly fix the architecture, we need to
have an explicit, distinguishable identifier partitioned from the locator.
Yes, the transition to this is not smooth, but unless we create a new
namespace, we are effectively endorsing the semantic overload that we have
today and will have to live with it in perpetuity.

People have used the address as an identifier precisely because they had no
other choice.  We have the opportunity to give them a better alternative.

Tony

---

From: "Tony Li" <[email-masked]>
Date: Fri, 20 Jun 2008 08:44:08 -0700

Bill,

|BTW, my counter proof to Tony's claim only addressed single-homed
|cases where PI is a necessary consequence of the requirements. Nearly
|all multi-vendor multi-homed cases require PI to function to an
|appropriate standard as well.

Can we safely assume that this is due to session resilience on link failure?
Or is there some other driver?

|We're well past the point where "PI for servers" should be considered
|an architectural requirement until proven otherwise.

Again, isn't PI a point solution?  While PA today is not currently
acceptable, your claim, if true, negates just about every solution presented
here.  I'm not prepared to accept it as axiomatic.

Tony

---

From: Dan Jen <[email-masked]>
Date: Fri, 20 Jun 2008 09:40:49 -0700

> today and will have to live with it in perpetuity. 

I'm not sure about everybody else, but lately I have had a lot of
trouble determining the constraints of our proposal.  I'll write what I
think is going on, and let me know if I made any mistakes.

We need an architecture that solves the scalability problem in routers,
while simultaneously providing easy multihoming and easy connectivity
change for customer networks.  The architecture must be made compatible
with v6.

For any proposal that requires any change(basically any proposal), there
is an apparent constraint that some driver must be present to ensure
that these changes occur.  I'll call it the 'driver constraint'.  Since
Tony wants a long-term solution, we can wait 30(more?) years for this
driver to appear or grow naturally.  We can even do things in that time
to encourage the growth of drivers.  But it still must be present, so
economic issues ARE relevant to us, correct?  Technical issues are also
relevant, of course.  But at some point, some network operator needs to
be motivated to make the changes necessary for the proposal.

The RRG has not yet been able to agree on what motivations are possible
in the long term (have we even decided on the duration of this 'long
term'?  1000 years?  50 years? 10 years?).  An example of this lack of
agreement is that Bill Herrin just made arguments for the need for PI
space due to some current operational practices.  Tony Li rebutted that
these practices can change over time.  Is it safe to assume that any
proposal requiring these changes must come with some reasoning that
these changes will indeed occur over time?  

Robin suggests that instead of trying to develop a general driver
constraint, we should recommend specific proposals and discuss them.
For any particular proposal, we know the changes proposed.  We can argue
about the feasibility of the changes and evaluate the proposal based on
this as well as the proposal's effectiveness, security, etc.  However,
Tony doesn't think this is a good course of action.

Currently, we are trying to nail down a detailed description of the
driver constraint that will serve as a guideline for any proposal.  The
driver constraint will be a long list of conditionals going 'if we did
action set X, in Y years, change set Z will be possible.'  

The purpose of this post is not to take a position.  I'm just trying to
make sure that I'm following what's going on.  Maybe this post will
generate discussion that gives me(and hopefully some others) a clearer
understanding of what everyone is currently trying to do here.  Thanks.

Dan Jen

---

From: David Williamson <[email-masked]>
Date: Fri, 20 Jun 2008 09:42:54 -0700

> other choice.  We have the opportunity to give them a better alternative.

Just to cause trouble, I entirely agree with both Bill and Tony.  As a
holder of PI space, and a site that sees PI as a hard requirement in
the present network, I entirely agree with Bill that some multi-homed
non-transit services, like my own, need unique identifiers in the
network to support VPNs, SMTP, etc.

On the other hand, I don't like it.  I'd really prefer to have a set of
unique identifiers for my site such that I never have to change them,
regardless of who my routing providers are - but I also don't want to
destroy the scaling properties of the network, and I'd like to have a
locater that is specified by my provider(s).

In short, Tony's right: we need to find an alternative to the current
regime.  Lacking any ability to do that, then my requirements suddenly
look just like PI, and we'll wonder where we're going in a handbasket.
This is definitely the time to fix this.

-David

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 20 Jun 2008 12:49:34 -0400 (EDT)

> From: "William Herrin" <[email-masked]>

    > Placing your mail server behind a NAT box ...
    > Placing your VPN concentrator behind a NAT box ...
    > ...
    > proven incorrect.

It's been clear for a long time that use of IPvN addresses outside of a site
as part of configuration elsewhere, as opposed to using DNS names, introduces
brittleness into the system.

So what I'm curious about is why people are doing that (using IPvN
addresses). Is it because there is some perceived robustness or security
issue with DNS? Or is it something where the fact that IPvN addresses and DNS
names aren't a 1:1 match is important? Or is it simply because it's 'easier'
to use IPvN addresses (no need to build in DNS resolution, etc)? (Or all of
the above, in differing cases?)

The reason that I ask is that if there's some perceived security/robustness
issue in going through a layer of resolution, then won't the same thing
happen all over again if we change the interpretation of IPvN addresses into
location-independent identifiers, which have to be mapped into some
lower-layer thingy which contains information on where the thing actually is?
Ditto if the mapping from those lower-level thing to IPvN addresses isn't 1:1
(which would be good for, e.g., multihoming); if the non 1:1 of DNS is an
issue, would a non 1:1 on identifiers/locators be an issue?

(And as an aside, I would assume any new namespace(s) would not have 1:1
mappings to existing namespaces, because if a new namespace is just a 1:1
mapping to an existing one, that greatly limits the power of the new
namespace. Other than the ability to change the binding over time, the new
names are inherently basically indentical in properties to the old ones...)

    > Placing your customer web servers behind a NAT box ...
    > They can't avoid that problem up front with CNAMEs to your DNS because
    > they often desire the same name that holds the NS and SOA records to
    > reach the web site.

Another place where the architecture has too few namespaces.
"somecompany.com" is overloaded as i) the website's secondary DNS name (after
www.somecompany.com), and ii) the NS/SOA name... (at least, if I understood
your point correctly).

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 20 Jun 2008 12:54:37 -0400 (EDT)

> From: Eliot Lear <[email-masked]>

    > know.

Hence my fondness for 'jack up' deployment approaches, which introduce a new
locator namespace below the existing IPvN addresses (which become endpoint
identifiers).

I've gone back and forth on this; an old routing architecture I did used this
as an interoperable deployment technique; then I played around with adding
endpoint identifiers above the existing internet layer; but I think now I'm
back to doing it below (because of the installed base issue).

Just out of curiousity, do you see these same arguments as applying to IPv6
too, even though deployment thereof is minimal? If so, is that because IPv6
is so similar to IPv4 that people will just use the same mindset on both?

	Noel

---

From: "William Herrin" <[email-masked]>
Date: Fri, 20 Jun 2008 14:39:18 -0400

> the above, in differing cases?)

Hi Noel,

In my own encounters, it has pretty much always been a question of,
"What works?"

Email reputation? Hundreds of ideas were thrown at the problem by
thousands of people working independently. Several stuck because they
were useful for identifying spam. Those included bayessian
classification and source IP address use history. Nobody planned it
that way and there was nothing dogmatic about it. It was just an
organic response to, "What the heck can we do to get an edge on the
spammers?"

IPSec VPNs? The most widely deployed product is the Cisco PIX/ASA. You
configure the cryptomaps with IP addresses and netmasks and if they
don't match on both sides, it doesn't work. It simply isn't possible
to configure them with something other than bare addresses. Is it even
practical to build an IPSec VPN appliance that configures and
reconfigures tunnels dynamically based on hostnames? Hostnames work
fine for SSL VPNs, but IPSec's function is so arcane that I'm not sure
it's possible to work with it in any other way besides bare IP
addresses.

I don't think perception of security plays a major role any more. It's
still waiting in the wings, but the major concerns at this point are
all practical: we have to operate in a manner compatible with what
that other guy is doing or our stuff won't work. The bottom line is
that our stuff has to work.

> www.somecompany.com), and ii) the NS/SOA name... (at least, if I understood

The point I was making is that DNS has no concept of, "this name has
the same IP address as that name over there." Instead it has CNAMEs
which mean, "the answer to this record is the same as the answer to
that record over there."

The difference is that no name which is a delegation component can
reference another name's IP address because the delegation components
have SOA and NS records which are unique to them. Www.mycompany.com
can have a CNAME but Mycompany.com can't. Since everybody wants
http://mycompany.com/ to go to their web site, this DNS CNAMEs don't
ease address renumbering.

Regards,
Bill

---

From: "William Herrin" <[email-masked]>
Date: Fri, 20 Jun 2008 14:53:00 -0400

> Can we safely assume that this is due to session resilience on link failure?

Hi Tony,

Barring the single-homed scenarios that are also relevant to the
multi-vendor multi-homed case, I think we can make that assumption. At
least nothing else jumps out at me. We can also eliminate the
single-vendor multi-homed non-server case since the addresses there
can be carved from the vendor's PA allocation.

> Again, isn't PI a point solution?

I'm not sure what you mean by point solution.

If one solution is known for a problem and despite years of attempts
no other solutions are found, should not that one solution gain
functional equivalence to an axiom?

It's hard to make meaningful progress if the group has to keep
stopping to re-prove that yes, there really is only one known solution
here and no, that alternate approach didn't pan out, and no that
clever idea won't work either, and yes it really sucks that we're
stuck with this but we are.

> While PA today is not currently acceptable, your claim,
> if true, negates just about every solution presented here.

Just so I'm not the one saying so. ;)  You'll notice that one of the
solutions it doesn't negate is TRRP.

Regards,
Bill Herrin

---

From: Eliot Lear <[email-masked]>
Date: Fri, 20 Jun 2008 22:31:57 +0200

Noel,
> is so similar to IPv4 that people will just use the same mindset on both?

I was making an observation, and attempting not to make a prediction.  
I'll have to think about your question some, but my initial response 
would be that it's more than just APIs, but what is going on from a 
security perspective that the reputation folk will look at, which is 
what I elaborated on earlier.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Jun 2008 09:00:38 +1200

> association from an IP address, and economic incentives for PI approaches.

As a matter of fact, this mess was identified by RFC 2101, but so far,
the incentives for change don't seem to have become compelling.

     Brian

---

From: "William Herrin" <[email-masked]>
Date: Fri, 20 Jun 2008 17:39:17 -0400

Tony,

Not with IPv4 or IPv6 I suspect. Their layer-4 protocols are already
firmly coupled to the layer 3 address and through APIs to the layer-7
applications. As long as they're coupled tightly, I expect that use of
the address for identifier purposes is inevitable.

Regards,
Bill

---

From: Robin Whittle <[email-masked]>
Date: Sat, 21 Jun 2008 13:15:38 +1000

Short version:     There are two kinds of PI space:

                     Today's BGP-managed PI space.
                     Scalable map-encap-managed PI space.

                   Any solution for IPv4 or IPv6 must implement
                   the requirement for easy change of providers
                   by providing PI space - no other approach
                   meets the needs of any end-user network with
                   servers.  Only the map-encap type of PI space
                   can be provided in a scalable fashion.

> multihoming and easy connectivity change.

As I argued at the start of this thread, for any practical IPv4 or
IPv6 solution in the foreseeable future, the only way a substantial
end-user network can change providers is to keep its public address
space when it moves.  There are far too many places where IP
addresses turn up in config files, DNS zone files etc. for a change
to these to be done securely and reliably.

Recent messages from Bill Herrin (which were supported in general by
Eliot Lear) highlight two other instances of IP addresses being
beyond the reach of any secure, robust, automatic update system: VPN
client config files and the historic reputations of mail servers as
used by spam detection software the world over.

Tony wrote to Bill:

> | We're well past the point where "PI for servers" should be
> | considered an architectural requirement until proven otherwise.
>
> acceptable, your claim, if true, negates just about every solution
> presented here.  I'm not prepared to accept it as axiomatic.

Bill's use of "PI", included a scalable new kind of PI space
available via map-encap (and perhaps other approaches), so I think
it is wrong to state that "PI for servers" isn't supported by
current proposals.

Currently there is only one way of providing Provider Independent
address space: advertise the prefix in BGP.  This leads directly to
the routing scaling problem we need to solve.

The map-encap systems provide a new kind of PI space.  It is just as
provider independent as the current kind, as long as the providers
have ETRs.

If there was only one map-encap end-user network prefix in every BGP
advertisement, then this new kind of space would have no scaling
benefits.

The explicit plan for Ivip is for a large prefix to be advertised in
 BGP and for this to contain many Ivip-mapped prefixes which
collectively serve the needs of many end-user networks - tens,
hundreds or perhaps tens of thousands.

LISP could clearly be used the same way, since for backwards
compatibility with networks without ITRs - to enable Proxy Tunnel
Routers to work - there needs to be a BGP advertisement of an
encompasing prefix for one or more enclosed EID prefixes.  I think
LISP can and should be used exactly as I described for Ivip: in
general, use it so that the advertised prefix contains many (tens,
hundreds, thousands etc.) of EID prefixes.

So both Ivip and LISP are perfectly capable of providing the new
kind of PI space in a highly scalable fashion.

I think the same is true of APT and TRRP.

 - Robin

---

From: [email-masked]
Date: Sat, 21 Jun 2008 10:57:34 EDT

In einer eMail vom 20.06.2008 18:42:50 Westeuropäische Normalzeit schreibt  
[email-masked]:

IMO v6 ( and v4) must be made compatible with an architecture which solves  
the scalability problem - and not the other way around. 
 
Recommendation: Try GOOGLE MAP, search for a route from New York to San  
Francisco and scroll along the blue path such closely zoomed so that you  can see 
the entire tightly meshed network of  the roads and streets. You  may notice, 
that the internet is much lesser meshed and much smaller - and yet  there is 
no scalability problem at all, only smarter routing  technology.  And we could 
do smarter routing too, well by adequate routing technology  (smartest (!!!) 
topology aggregation) and not by entering that we want to visit  some friends, 
and please find out by yourself, that these friends live in San  Francisco.
 
Going for a long-term solution means giving up address aggregation from the  
90s. It is the wrong paradigm. Not smarter address aggregation but smarter 
than  Dijkstra routing is needed.
 
Heiner

---

From: Peter Sherbin <[email-masked]>
Date: Sat, 21 Jun 2008 10:47:07 -0700 (PDT)

>...if we want to truly fix the architecture...

Assuming the "end-to-end" axiom it seems that the discussion so far circles around a few "to". That could mean one of the following:
1. There is a universally accepted definition of the "end"
2. Any particular "to" defines its own "ends"

The #1. above seems unlikely. IMO the starting point of the new architecture is a clear definition of the "end"-point in networking communication. That entity is the one that requires identifiers. Also current multiple "ends" encourage NATs, which will exist as long as the user definition of the "end" differs from that of IETF.

If you see a merit in the above line of thought please let me know so I can paint a perspective on the "ends" under IPv6.

Thanks,

Peter

---

From: Scott Brim <[email-masked]>
Date: Mon, 23 Jun 2008 15:19:50 -0400

> other choice.  We have the opportunity to give them a better alternative.

Got it.  It's clear that we need a node identification mechanism that by 
some means has to persist at least as long as any particular packet 
exchange lasts.  This could be done by any combination of functions at 
multiple layers.  Given that so much of Internet traffic is going to be 
with mobile endpoints, I don't see how can continue using the current 
"address" as an identifier good enough to support session continuity. 
The only way I can think of is to isolate applications from what's 
really going on underneath, and present them with a token they can use 
for identification and allow them to think it's a real address.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jun 2008 09:11:46 +1200

On 2008-06-24 07:19, Scott Brim wrote:
...

> "address" as an identifier good enough to support session continuity.

Well, that's exactly why Mobile IP uses the home address as a session
ID and the c/o address as a locator. Fundamentally the LISP class
of RRG proposals does the same thing (oh, and so does shim6).

> for identification and allow them to think it's a real address.

Bingo. This is where NAT goes wrong - it presents different tokens
at the two ends.

   Brian

---

From: [email-masked] (Noel Chiappa)
Date: Mon, 23 Jun 2008 19:37:25 -0400 (EDT)

> From: Scott Brim <[email-masked]>

    > Given that so much of Internet traffic is going to be with mobile
    > endpoints, I don't see how can continue using the current "address" as
    > an identifier good enough to support session continuity. The only way I
    > can think of is to isolate applications from what's really going on
    > underneath, and present them with a token they can use for
    > identification and allow them to think it's a real address.

General agreement with all thatw, but I query the "I don't see how [we] can
continue" part. Look at what the phone system did, when faced with demands
for number portability (i.e. provider independence), etc. They still use
'phone numbers' in the existing externally-visible interface, but those are
now directory entry names, and get mapped into 'real' phone numbers away from
the sight of the users.

Which reminds me of another observation I had about IPv4 - it has the same
packet format for router-host and router-router interactions. Now, there's no
law of nature that says they have to be the same - it was done that way, back
when, for reasons of simplicity and economy of effort - but if there's a good
engineering reason to use differing ones, I don't see any fundamental reason
not to. We could keep the IPvN packet format as a service interface, and use
something else between the routers.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Mon, 23 Jun 2008 19:56:03 -0400 (EDT)

> From: Brian E Carpenter <[email-masked]>

    > This is where NAT goes wrong - it presents different tokens at the two
    > ends.

Yes, but that's an almost unavoidable consequence of the agglomeration of the
two main principles of NAT: i) no change to the hosts on either end, and ii)
multiple disjoint scopes for subsets (perhaps complete subsets) of the
address namespace.

I mean, if host X has address Ax in its local (source) scope, then unless
that host can somehow be assigned the same address in the foreign
(destination) scope, it is of necessity going to "present[] different tokens
at the two ends".

In other words, one can't take an N-bit namespace with local scope, and say
'this block is for local hosts, and foreign hosts get mapped (on demand) into
that block', and avoid hosts having different addresses at the two ends -
they have to have names out of different blocks of the namespace at the two
different ends.

(If one tries saying 'well, the local block at site P is this block, and that
other block at Q', and so on, so a host can have the same name (address) at
both ends, one has basically reinvented unique globally-scoped name...)

The only way to guarantee that hosts would have the same address at each end
would be to negotiation between the two ends, and find an address which is
free in both local scopes which both can then agree to assign to that host -
which probably breaks assumption i). And then if host X wants to talk to
hosts P and Q in different addressing scopes, one is almost for sure looking
at X having two different addresses at the same time - one to use when
talking to P, and the other for Q. Again, needing a change to the hosts.

If we'd been able to change the hosts, local naming scopes could have been
done a lot cleaner...

	Noel

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 24 Jun 2008 12:03:52 +0800

>     > an identifier good enough to support session continuity. The only
way
> I

If so, the problems with map&encap approachs will still exist in your
mentioned approach, such as initial packet loss/delay due to the id/loc
mapping. Why not implement the map&encap function on the hosts since a
clean-slate approach is welcomed? 

Best regards,
Xiaohu XU

---

From: Shane Amante <[email-masked]>
Date: Mon, 23 Jun 2008 22:39:08 -0600

Noel,

Sorry for the delayed reply.  Please see below.

> the above, in differing cases?)

IMO, it's largely due the latter, for a few reasons:
1)  Laziness, i.e.: IPvN addresses "just work", (for the most part);
2)  In addition, consider the case where the majority of "network  
equipment" implementations offer administrators no other choice, but  
to use IPvN addresses in, for example, router ACL's, firewalls, NAT  
rules, etc.  For example, consider that there's no 'standard' way to  
define IP prefixes in DNS, which means those devices would have to  
rely on DNS for hostname resolution and 'something else', e.g.:  
something analogous to IRR data, for "name to IP prefix  
resolution" ... therefore, administrators would rather just use IPvN  
addresses and keep it simple.
3)  Finally, there's the robustness (i.e.: avoid creating a circular  
dependency via DNS or other 'ancillary' system) and security concerns,  
which you already mentioned.

One concern, particularly with #2, is if we do an ID/LOC split are we  
punting this 'brittleness' to a higher layer of the stack, i.e.:  
pushing it to the EID layer, since EID's are, for all intents and  
purposes, "permanently" assigned to a site.  Or, is that brittleness  
acceptable/OK?  Said a different (more constructive way), perhaps it  
would be nice to think about fixing "naming" bi-directionally?
1)  Down the stack, from EID to RLOC's;
2)  Up the stack, from EID to: a) "policy enforcement points" (or  
other network infrastructure that's going to do something besides,  
perhaps, forwarding on them), b) "applications", etc.  Or, perhaps  
this is biting off more than we can (or want to) chew?

-shane

---

From: David Conrad <[email-masked]>
Date: Tue, 24 Jun 2008 19:56:50 -0700

On Jun 23, 2008, at 9:19 PM, Scott Brim wrote:
> It's clear that we need a node identification mechanism that by some  
> means has to persist at least as long as any particular packet  
> exchange lasts.  This could be done by any combination of functions  
> at multiple layers.

Indeed.  Much of the discussion has been where to do the separation.

Outside of the network stack via ETR/ITR or equivalent
At the IP layer via SHIM6
At the transport layer via SCTP or equivalent
At the application layer via a "network handle" concept (i.e., present  
the application an index into a kernel-maintained table with the  
kernel handling address change, modeled after Unix file handles).

The farther you move down the stack, the wider the scope of an address  
change (e.g., changing the address in the ETR/ITR model impacts all  
devices serviced by the ETR/ITR, changing the address in a 'network  
handle' affects only the process using that address).

> endpoints, I don't see how can continue using the current "address"  
> as an identifier good enough to support session continuity.

Hide the address change within the infrastructure of the layer.  E.g.,  
in the 'network handle' model, a change gets signaled to the kernel  
and if the session is using TCP, the kernel shuts down the connection  
to the old address and opens a new connection to the new address.  In  
the ETR/ITR model, no such gymnastics are necessary, of course, as the  
applications or even the hosts behind the ETR/ITR never see a change.

> really going on underneath, and present them with a token they can  
> use for identification and allow them to think it's a real address.

Right.  Much of the ickiness we're dealing with is due to the fact  
that applications and transport layers know _far_ too much about what  
is beneath them.  Layering violations hurt.

Regards,
-drc