Subject: [arch-d] Benefits of identity/location separation?

From: [email-masked] (Noel Chiappa)
Date: Sun, 22 Apr 2007 11:01:25 -0400 (EDT)

I was recently talking with someone of the recent discussion, and they made
the point that they hadn't seen a clear enumeration of the benefits of
separation of location and identity.

This is something I tend not to think about in detail, because I am always
mindful of the Great Architecture dictum ("the hallmark of great architecture
is not how well it does the things you knew it needed to do, and it was
therefore designed to do, but how well it does things nobody had thought of
at the time it was designed"). E.g. nobody who did TCP/IP had any real idea
of the Web (the closest we came was something like the world of John
Brunner's "Shockwave Rider"). Not surprising; new things tend not to get
thought up until the architecture enables them. So, I tend to think in a very
different way (asking things like "does this structure express some
fundamental truth about the way things ought to be organized").

However, it would probably be a useful exercise if we can enumerate, and to
some degreee evaluate, all the *immediate* benefits which separation of
location and identity will give us. Here are the ones I can come up with:

- Multihoming: A number of aspects of multihoming are easier with separation.
  Specifically:
  - Avoiding having to give hosts multiple "addresses". With anything vaguely
    like the current routing architecture, we cannot support widespread
    multihoming purely within the routing (i.e. PI addresses). The only other
    technically feasible approach that years of work have identified is for
    such hosts have to have multiple addresses. Howeever, this seems to be
    an operation non-starter, and is the big objection to designs like SHIM6.
  - Keeping connections open if one address becomes unreachable (this applies
    to hosts with multiple interfaces too).

- Provider independence for small organizations: It's much easier to switch
    providers if the low-level naming of hosts doesn't change when this
    happens. Currently, the only other ways to provide this are PI-addresses
    (which don't scale to support many small sites), and NAT.

- Mobility: Mobility (especially as distinct from portability - the former
    term is taken to include keeping connections open) is basically
    impossible without separation of location and identity. Mobile6 basically
    does this now, albeit with both namespaces being IPv6 addresses.

- Multicast: Right now, the notion of the membership of a multicast group,
    and the distribution tree thereto, are inherently entangled. My feeling
    is that until we can separate the two, widespread multicast (especially
    lots of small groups) will be technically infeasible.

Alas, I have a feeling I am missing a great deal, but I don't think well at
this level. Can others expand on this list?

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: JFC Morfin <[email-masked]>
Date: Mon, 23 Apr 2007 01:09:17 +0200

Dear Noel,
I do not see any advantage myself, except that by chance it can 
support better some of the needs of the three addressing (fixity, 
mobility, and virtuality) layers, than the default current fixty only 
layer violation.
jfc

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 23 Apr 2007 07:47:40 -0700 (PDT)

Could we look at Mobility as a general case where separation is required. Static
sites are treated as mobile only not in motion.

Peter

> this level. Can others expand on this list?

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Apr 2007 08:31:01 +0200

There's a sense in which Noel's question was in my mind when I wrote
draft-carpenter-idloc-map-cons-00.txt. Noel has told me he's going
to comment on that on the RAM list, but here would work too...

Just to complete the picture, we should probably also document the
disadvantages of identity/location separation.

Quoting my own draft:
    As implied by the previous section, there are cases where a split
    would increase rather than decrease confusion.  Enterprise network
    operations would be turned upside down.  Firewalls would have to deal
    with fundamental change, since identifiers rather than locators would
    be the focus of many attacks.  The way the DNS and the socket API are
    related to each other might change.  Any upper layer implementation
    that believes that an IP Address is both a Locator and an Identifier
    would be in even greater trouble than today.  And of course the
    fragile superstructure built on NATs and ALGs would be severely
    challenged.
These are all practical, operational disadvantages. Are there any
architectural disadvantages?

     Brian

---

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Apr 2007 05:51:55 -0700

> location and identity will give us. Here are the ones I can come up with:

This is an important exercise, but it is equally important that it be 
done with sufficient scope.  For example, as Brian suggests, the 
negatives also have to be considered.

I also suggest that the characteristics of the split can have a massive 
impact on the characteristics of the result.

An obvious example is the level at which the constructs are provided. 
Since locator must remain with IP, the question is where the identifier 
is used and whether it is globally unique, persistent and/or public.

So, for example, it can be observed that we already have one kind of 
loc/id split, between IP Address and Domain Name.  That has some 
strengths and it has some weaknesses.  Any other choice for creating a 
new identifier venue will equally have trade-offs.

Further, the granularity of the benefits (goals?) makes a difference. 
The need to have the IP layer support identifier is based on some 
critical assumptions.

For example, there is a continuing assumption that two flows with 
different locator-pairs must be handled in the aggregate, by the IP 
infrastructure, if they are part of the same upper-level transmission, 
such as a TCP connection.  While this sounds completely reasonable, it 
well might not be necessary or even appropriate.

For example, just as a route tends to be relatively stable for the life 
of a given TCP connection, the amount of locator-pair changeability 
during a connection might actually be quite small.  If it is, then there 
is no real need for the IP infrastructure to know that the different 
locator-pairs are related.  This, in turn, means that the identifier 
might well be appropriate to provide at a higher layer, rather than a 
lower one.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 24 Apr 2007 08:50:47 -0700

Noel, 

I'm glad you raised this thread, since answering the question in the
Subject: field of this email is what the HIP research group is chartered
to explore (in the context of the HIP proposal specifically). 

First, I think that the answers depend on the nature of the identifiers.
Specifically, are they routable or usable as locators in some context,
and do they have any inherent security properties?  Second, the answers
will also depend on how much one assumes that DNS or another service is
available to facilitate the bindings.

>     multihoming purely within the routing (i.e. PI 
> addresses). 

Do you refer above to a border-router address rewriting approach?

> The only other

I think that the above needs to be qualified.  It may be that, in a
large enterprise-managed situation, this is operationally problematic.
However, if you have multiple interfaces, especially through multiple
technologies or providers, then you may have to have multiple addresses
at the host.

Maybe multihoming category should be split into "site" and "host"
multihoming variants.  

>     to hosts with multiple interfaces too).

agree

>     does this now, albeit with both namespaces being IPv6 addresses.

I agree that this seems impossible to have L3 mobility without some form
of split.  HIP and mobile IP have similar solutions (both early- and
late-binding approaches) using different identifier spaces.

I think an open question, however, is how much it helps operationally.
Network-level ID/locator splits seem to help most when roaming across
different layer-3 networks (different ASes).  However, it seems that
users most often are moving within a single provider's network and not
hopping across providers (the so-called vertical handoff).  I wonder
whether there will be enough incentives for providers to support the
vertical handoff modes of mobility.  The intended seamless experience of
roaming across layer-3 networks, perhaps with disconnection, may be
defeated by things like ssh session timeouts and http capture agents.  

>     lots of small groups) will be technically infeasible.

Can you expand on this point?

> this level. Can others expand on this list?

Architecturally, a split allows for late-binding approaches to
resolution (e.g., the DTN or i3 architectures, mobile IP home agent)
which may allow novel solutions to rendezvous, privacy, and delegation.

Security (including privacy) is another issue that could be weakened or
strengthened by a split, depending on the nature of the split.

Tom

---

From: John Day <[email-masked]>
Date: Tue, 24 Apr 2007 21:02:16 -0400

I think "patch" would be a better characterization of the benefits to 
the so-called loc/id split problem.  As we both know solving the 
loc/id split is not the whole problem.  I have not seen a solution to 
the loc/id split that scales.

As far as things like the web:  As Alan Kay pointed out not long ago, 
the developers of the web would have done well to look at NLS first. 
While NLS was single-site at the time, that wasn't a limitation of 
the design, only the times.  It was much closer to what we should 
have had.

However, I am more concerned by the responses that don't see that 
there is a problem that needs to be solved.  This is one of several 
fundamental problems we have known about for 35 years that remain 
unresolved. It begins to look more and more like the IETF/Internet 
has acquired a mind set more like the phone companies in 1970s than 
networking of the 1970s.

But you are right, the mark of a good architecture is one that solves 
problems that were not designed in.

Take care,
John

---

From: John Leslie <[email-masked]>
Date: Tue, 24 Apr 2007 22:03:21 -0400

Noel Chiappa <[email-masked]> wrote:
> 
> ... (asking things like "does this structure express some fundamental
> truth about the way things ought to be organized").

   (For example, the difference between a host and an interface? ;^)

> However, it would probably be a useful exercise if we can enumerate,
> and to some degreee evaluate, all the *immediate* benefits which
> separation of location and identity will give us.

   I usually refuse to list any "immediate" benefits...

> Here are the ones I can come up with:
> 
>   - Avoiding having to give hosts multiple "addresses".

   It's more a matter of avoiding the pitfalls of multiple "addresses"
for a host. We're going to end up with multiple "locators" for an
interface anyway, which isn't the same problem at all...

>     With anything vaguely like the current routing architecture, we 
>     cannot support widespread multihoming purely within the routing
>     (i.e. PI addresses).

   That's not actually the problem: we can assign PI addresses to several
orders of magnitude more hosts; what we can't do is have routing do
anything "reasonable" about them.

   Folks who pay thousands of dollars per month for redundant connectivity
_really want it to _do_ something. They will insist on fiddling the knobs
until they believe it _is_ doing something.

   Routing, OTOH, _really_ needs to avoid routing loops. In most cases,
there's nothing routing can do to effectively use redundant connectivity
without creating a danger of routing loops.

   Actually, it's even worse: routing can't even tell the difference
between a congested link and a failed link. We have to settle for a
generic timeout to declare a link to have failed, which leads to _both_
mistaking congestion for failure and failure to switch to an alternate
path quickly enough. That decision, IMHO, doesn't belong in routing...

   Loc/ID split would give us the tools to recognize multiple paths of
a single "connection", enabling load-sharing and "instant" switching
upon path failure or sudden increase in congestion.

   (That would require _some_ changes in TCP stacks -- perhaps only to
the congestion control if we hide the locator manipulation from the TCP
stack itself...)

>     The only other technically feasible approach that years of work
>     have identified is for such hosts have to have multiple addresses.

   Do you mean the likes of SCTP?

>     However, this seems to be an operation non-starter, and is the
>     big objection to designs like SHIM6.

   Actually, I think there are other "big" objections to SHIM6...

>   - Keeping connections open if one address becomes unreachable (this
>     applies to hosts with multiple interfaces too).

   I think you should have stopped after "open".

   For years I was saying that the Internet was designed to survive
World War III -- by patiently waiting for civilization to rebuild,
and then resuming where it was interrupted.

   We should be able to keep connections open, period. If somebody
unplugs his laptop from his office ethernet, it should be able to
continue downloading over the office wireless, stall intermittently
while he drives home, and pick up speed again when he gets home to
his cable "broadband" connection. Applications shouldn't have to
deal with this: it should come "for free" in the operating system.

   This would require exactly the same changes to TCP stacks.

> - Provider independence for small organizations: It's much easier to
>   switch providers if the low-level naming of hosts doesn't change
>   when this happens.

   "Renumbering" is a horror, because synchronizing any access at all
to hundreds of hosts is practically impossible. (Not to even mention
work necessarily interrupted.)

>   Currently, the only other ways to provide this are PI-addresses

   (NAT should be our friend. NAT _could_ be our friend, IMHO. NAT
_could_ handle most of what we need if we could migrate congestion
control to it...)

> - Mobility: Mobility (especially as distinct from portability - the
>   former term is taken to include keeping connections open) is
>   basically impossible without separation of location and identity.

   While literally true, I'd avoid saying it that way.

   Most folks don't take "mobility" to imply keeping connections open.
It's something we could do with a proper loc/ID split, yes, but most
folks think it's OK so long as their browser window works and checking
their email remains automatic.

   I think we need to talk of "seamless mobility", where applications
no longer need to pay any heed to whether the host is mobile.

>   Mobile6 basically does this now, albeit with both namespaces being
>   IPv6 addresses.

   Assuming you mean Mobile IPv6, I don't agree it does any sort of
namespace split. In effect it merely maintains a tunnel from a "home"
locator to the mobile locator, which remains invisible to the other end
of any connection.

   BTW, I see no reason something looking exactly like an "IPv6 address"
can't be an "identifier", rather than a "locator". It just isn't what
Mobile IPv6 does.

> - Multicast: Right now, the notion of the membership of a multicast
>   group, and the distribution tree thereto, are inherently entangled.
>   My feeling is that until we can separate the two, widespread
>   multicast (especially lots of small groups) will be technically
>   infeasible.

   I wouldn't go that far: multicast _is_ technically feasible: it just
depends upon non-scalable mechanisms for its operation. Loc/ID could
give us some opportunities for alternative multicast routing paradigms;
but I'm not sure that's where multicast stalls.

> Alas, I have a feeling I am missing a great deal, but I don't think
> well at this level. Can others expand on this list?

   I don't think you're missing all that much -- within today's paradigms
of what the Internet does...

   Nonetheless, there is certainly a need to list "protection from
routing meltdown". Once we have a way -- outside routing -- to find
alternate paths to a host, we can escape the feature-creep that's
increasing the danger of routing meltdown.

   We also could explore entirely different routing paradigms if we
were freed from the expectation of "quickly" finding alternate routes.

--
John Leslie <[email-masked]>

---

From: John Leslie <[email-masked]>
Date: Tue, 24 Apr 2007 22:37:19 -0400

> to comment on that on the RAM list, but here would work too...

   I'd be happy to discuss it here...

>    operations would be turned upside down.

   That overstates the case, IMHO.

   If a host ("stack") has multiple locators, they're still all under
the control of the enterprise. The enterprise would have _more_ freedom
to enforce traffic-shaping. The enterprise would have the _same_
ability to control assignment of locators that it now has for
assignment of IP addresses.

   The enterprise _would_ have to deal with assignment and tracking
of multiple locators.

>    Firewalls would have to deal with fundamental change, since
>    identifiers rather than locators would be the focus of many attacks.

   Their are some schemes being proposed that would tunnel IDs past
firewalls. Hopefully saner heads will prevail: otherwise switches will
have to be designed to enforce "source IP" filtering.

   This problem is not generic to loc/ID splitting: it results from
implementation details.

>    The way the DNS and the socket API are related to each other might
>    change.

   Indeed... There are many ways to publish ID/loc mappings...

>    Any upper layer implementation that believes that an IP Address is
>    both a Locator and an Identifier would be in even greater trouble
>    than today.

   We might do well to try to compile a list of these: nothing jumps
out at me as an example which assumes _both_...

>    And of course the fragile superstructure built on NATs and ALGs
>    would be severely challenged.

   It already _is_ severely challenged.

   For most purposes, we can assume that any migration to loc/ID which
takes a year or more will be a slower cycle than the evolution of the
threats NATs claim to ameliorate. Nonetheless, listing a few weak
areas would be good.

> architectural disadvantages?

   I can't think of anything I'd call an "architectural disadvantage"
of splitting loc and ID. (There certainly are architectural disadvantages
of some specific proposals...)

---

From: John Leslie <[email-masked]>
Date: Tue, 24 Apr 2007 23:06:58 -0400

> negatives also have to be considered.

   Agreed.

> impact on the characteristics of the result.

   The devil, as always, is in the details; but a clean split need not
break things not already "broken".

> is used and whether it is globally unique, persistent and/or public.

   Out of scope, IMHO.

   Or to say it differently: Identifiers should be used above the
internetworking layer, they may or may not be globally unique, they
should persist long enough to satisfy the needs of the layer using
them, and some will be public while others are not.

   (I will stipulate that some proposals propose making identifiers
visible to lower layers; however much I dislike this, it doesn't change
the statement above.)

   (I further stipulate that some proposals try to be more restrictive
than the statement above: they are simply wrong, and will be defeated
in the marketplace if necessary.)

> new identifier venue will equally have trade-offs.

   Its weaknesses are mostly historic (but we will have to live with
them).

   We should note that DNS _could_ serve almost any imaginable loc/ID
mapping, but the current usage maps mostly services, not stacks.

> The need to have the IP layer support identifier is based on some 

   ... all wrong-headed, IMHO.

   Besides, I don't consider that "granularity". It's simply a
misunderstanding of what an identifier _is_.

> well might not be necessary or even appropriate.

   It doesn't sound the least bit "reasonable" to me.

   The IP infrastructure should forward packets, period. It should not
worry about "aggregates"; it should be blissfully unware whether there
_is_ any such thing as an "upper-level transmission".

   TCP should have no difficulty "routing around" problems this might
introduce, except that congestion control has gotten so intertwined
with details of the current IP infrastructure that we cringe at any
thought of changing it.

> of a given TCP connection,

   (often false)

> the amount of locator-pair changeability during a connection might
> actually be quite small.

   Might... or might not...

> If it is, then there is no real need for the IP infrastructure to
> know that the different locator-pairs are related.

   There should be no such need in either case.

> This, in turn, means that the identifier might well be appropriate
> to provide at a higher layer, rather than a lower one.

   Agreed!

---

From: Tony Li <[email-masked]>
Date: Wed, 25 Apr 2007 01:40:06 -0400

On Apr 24, 2007, at 9:02 PM, John Day wrote:

> As we both know solving the loc/id split is not the whole problem.

John,

What would you say is "the whole problem"?

> has acquired a mind set more like the phone companies in 1970s than  

I think it's unfair to paint the entire IETF this way.  There are  
those that are still unconvinced.  I find it telling that those that  
are unconvinced are not those who will be called upon to fix things  
when we get to a full-fledged 'crisis'.

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 25 Apr 2007 02:40:54 -0400

> mapping, but the current usage maps mostly services, not stacks.

More generally, I think that we should note that DNS can, with  
sufficiently clever encoding, provide almost any arbitrary mapping  
function that we can think of.  Hacks like in-addr.arpa already give  
us a mapping from integers to strings, so we clearly have  
considerable flexibility.

It's not just a distributed relational database, it's also a floor  
wax and desert topping!  ;-)

Tony

---

From: Jari Arkko <[email-masked]>
Date: Wed, 25 Apr 2007 14:21:08 +0300

John,

> the loc/id split that scales.

Not sure I understand what you mean with "the whole problem". Loc/id split
is not a problem to begin with, its a solution designed to address a
particular
set of problems. I do agree that there are challenging aspects in this
solution, and we need to see how scalable the mapping table distribution
mechanisms are going to be, for instance. Or Brian's list of operational
issues. The verdict is still open, but I think the approach is promising.

> there is a problem that needs to be solved.

I would suggest moving past this argument. It is true that there are
differing
opinions with regards to how urgent this issue is or how well we can create
hardware to deal with it. But at the end of the day we know we have a
situation where local events and state are visible on a global scale.
There is no disagreement about that. As far as I know, there is also no
disagreement about whether we should work towards a more scalable
architecture.

Bottom line: arguing about the level of urgency isn't going to move us
forward. Having a design that can actually solve some of our problems
does take us forward, however. Lets work to get to that design! And
yes, we do need to understand the impacts of the design, both
positive and negative.

Jari

---

From: John Day <[email-masked]>
Date: Wed, 25 Apr 2007 07:48:34 -0400

>What would you say is "the whole problem"?

RFC 1498.  You need another identifier. Just having points of 
attachments and application names isn't enough.  The loc/id split 
characterization points at a solution space that won't scale.  But 
this is well understood.  One could even say it is basic to CS.  ;-)

>when we get to a full-fledged 'crisis'.

I agree.  We have known about this problem since 1972.  We had a 
chance to fix it 15 years ago and refused.  It is long past time to 
do it.  We need to be more proactive.  When you build a house, you 
don't wait until it looks like rain to think about what a roof should 
look like.   If you do, then you just throw something up that takes 
care of this shower, but may be completely inadequate for the next 
storm.

I am concerned that we have become more like the phone companies of 
the 1970s than the networking of the 1970s.

While I empathize with your comment about DNS being a dessert topping 
and a floor wax ;-), I am also concerned that we need to work on 
reducing the "parts count" rather than increasing it.  This thing is 
getting more and more unwieldy.  It is starting to feel like all of 
those add-ons to DOS years ago, rather than new things that just 
nicely fit in.

Take care,
John

---

From: John Leslie <[email-masked]>
Date: Fri, 27 Apr 2007 12:12:28 -0400

Brian E Carpenter <[email-masked]> wrote:
> 
> draft-carpenter-idloc-map-cons-00.txt

   Brian deserves some serious discussion of this.

   (It has taken a while to digest it all...)

   First, he states some good definitions:
] 
] A stack is defined as one participant or the process on one side of
] an end-to-end communication. (quoted from NSRG)
]...
] Locator: A binary quantity (not necessarily an IP Address) that can
] be used by a routing or forwarding device to decide where to send a
] packet.
] 
] Identifier: A binary quantity (not necessarily an IP Address) that
] can be used by a Stack "A" to uniquely identify another Stack "B"
] both for bilateral communication and for informing a third Stack "C"
] that it should communicate with stack "B".

   We need to keep these firmly in mind.

   It's still a somewhat open issue exactly _what_ we mean an "identifier"
to identify; but I'll proceed as if we had agreed to ID a "stack".

   IMHO, the major purpose of a stack ID is to give assurance to the
other end of a communication that it's talking to the right entity.
There are various cases in current-day TCP/IP where the IP Address
is used for that, on the theory that we know the packets we send are
being directed there; we should be looking for something stronger.

   Brian quotes RFC2101:
] 
] Due to dynamic address allocation and increasingly frequent
] network renumbering, temporal uniqueness of IPv4 addresses is no
] longer globally guaranteed, which puts their use as identifiers
] into severe question.  Due to the proliferation of Intranets,
] spatial uniqueness is also no longer guaranteed across routing
] realms...

   Clearly, IPv4 addresses are becoming less useful as Identifiers.

] The IAB feels that... the transition to IPv6 would be an ideal
] occasion to provide upper layer end-to-end protocols with temporally
] unique identifiers.

   How close we've come in the intervening ten years is in question.

   Brian observes:
] 
] ... we can loosely divide upper layer implementations (transport layer
] and above) into two classes:
] 1.  Those that use a socket API, or the equivalent, on the
]     traditional assumption that an IP Address is simultaneously a
]     unique Locator and a unique Identifier...
] 2.  Those that avoid this assumption, for example by creating their
]     own namespace or relying completely on the DNS.

   Brian predicts confusion within traditional socket-API implementations
when Locator and ID are no longer the same. Avoiding this confusion
weighs heavily on the remainder of his draft.

   But we're discussing architecture: we don't need to retreat at the 
first hint of confusion.

   There's no reason a (suitably evolved) socket API couldn't
distinguish Locator from ID, defining the socket by the IDs while
constructing packets with the locators.

   Brian continues:
] 
]  The predominant assumption is that the IP Address of a network element
] (router, switch, bridge, server or user device) both identifies and
] locates it.

   This is pretty much true by definition for Layer 3 (which should
remain blissfully unaware of all the higher-layer gadgets which break
the assumption).

] The assumption generally made by operations staff is that there is
] a single namespace; the notion of an identifier-locator split is
] unknown.

   True, but irrelevant.

   Brian goes on to contend:
] 
] that no solution which removes the ability of upper layers and
] management systems to treat the Identifier and Locator Namespaces as
] identical within some well defined context is deployable in practice.

   (His wordsmithing makes this unassailable as written...)

] ... at the level of packet transmission, and the network elements and
] Stacks that handle them, we need unified Namespaces within certain
] Namespace Contexts.

   I've already stipulated this for Layer 3; but that doesn't mean
we need unified Namespaces within everything that interfaces to Layer 3.

] In practice this means that network elements and Stacks need to be
] able to treat things that look like an IP Address as they do today,
] but with a clear definition of the context within which Identifiers
] and Locators are the same thing, and of the contexts in which they
] are not.

   Un-evolved Stacks _will_ treat IP Addresses that way; that's not
our concern when discussing architecture.

] Within its site, A must have an Identifier and Locator that match
] 1:1...

   Here, Brian and I part ways. He wants to split by physical position;
I want to split by Layer.

] When communicating with B, A must provide an Identifier that B can
] rely on, and conversely.

   Agreed.

] A must also be able to communicate with C on the same basis, and
] furthermore tell C that it may communicate with B as part of the same
] application.

   Agreed, but we must be careful not to read too much into this. By
communicating an ID to C, A does _not_ undertake to tell C _how_ to
reach B -- only how to tell _whether_ C has reached B. Finding a
locator is out-of-band, and should be subject to B's security policies.

   Brian concludes:
] 
] o  On-site, Identifiers and Locators should not be split.

   His opinion; not mine.

] o  To go off-site, it is necessary to know which Locator leads
]    towards a given Identifier.  Either the sending Stack or its
]    router could know this.

   Ideally, the interface to Layer 3 would find _a_ locator. There
are many possibilities during transition to a new architecture.

] o  The Identifier of the sending Stack must be delivered unchanged to
]    the receiving Stack.

   I agree (and would further suggest that IDs be tamper-resistant).

] o  It must be possible to refer third party Stacks to a remote
]    Stack's Identifier.

   Agreed.

   Brian goes on to discuss mapping locators to and from IDs.

   In this email, I'll limit myself to stating that if _every_ ID
must publicly map to a locator, and vice-versa, we're not talking
about a loc/ID "split". Thus I'd rather not go into detail about
concerns with Brian's mapping proposals (yet).