It is well established that naming, addressing and routing are conceptually
separate (or should be!) [IEN19, IEN48, RFC1498] are formative in this regard.
For a long time, the view in the the IETF community was that DNS took care
of naming, IP took care of addressing, and routing protocols took care of
routing. As growth in the Internet accelerated, cracks appeared in this
simplistic view [RFC2101, RFC2775].

Emerging issues such as multihoming, the need for sites to change ISPs,
mobility, and end to end security have led to increasing perception that
the "addressing" concept has two very distinct aspects:

- identifying something
- locating something

It might be thought that "identifying something" is what a name does.
But it turns out that 'example.com' (which in the original concept
of DNS would have identified a specific interface on a specific
computer) is in fact a virtual name that generally identifies
a company called 'Example' and typically leads to a server pool
(i.e. multiple computers). Here, we are not talking about that.
We are talking about identifying network level entities -
put simply, they could be individual TCP/IP stacks or they
could be conglomerates generally known as "sites".

The word "stack" was defined as the entity to be identified
by the IRTF Namespace Research Group in an unpublished document
(draft-irtf-nsrg-report) thus:

"  Today, a host may represent multiple entities.  This happens when a
    service provider hosts many web sites on one server.  Similarly, a
    single entity may be represented by multiple hosts.  Replicated web
    servers are just such an example.  These entities are "protocol
    stacks" or simply "stacks", instantiations of the TCP/IP model, be
    they across one or many hosts.  A stack is defined as one
    participant or the process on one side of an end-to-end
    communication.  That participant may move and may be represented by
    multiple hosts...

    Each instance of a stack has a name, a "stack name".  At an
    architectural level the Name Space Research Group debated the value
    of such names, and their associated costs.  Forms of this name are
    used in numerous places today.  SSH uses public/private key pairs to
    identify end points.  An HTTP cookie anonymously identifies one end
    of a communication, in such a manner that both the connection and the
    IP address of the other end point may change many times.  Stack names
    are intended to identify mobile nodes, devices behind NATs, and
    participants in a content delivery or overlay network."

To send a packet to a stack, we need its identity and we need to
know where that identity is currently located. Today stack identity and
stack location are both somehow combined in an IP address (whether it's
IPv4 or IPv6 doesn't matter.) If a stack is identified as
10.1.2.3 we expect the routing system to treat this as a stack locator.
Similarly, if a site is identified as 10/8, we expect the routing system
to treat this as a site locator. But this example is deliberately
a broken one - we know that address and that prefix are ambiguous, and
have no global value either as identifiers or as locators. Yet within
a given network using private addresses, 10.1.2.3 is a perfectly
good stack identifier and locator, and 10.1.2/24 is a pefectly good subnet
locator.

What is going on here is an illustration of a much more general
observation: an IP address, or an IP prefix (the high order bits
of an address) can be a stack (or site) identifier, a locator,
neither, or both simultaneously *depending on context*.

To be specific:

- inside a NATted site, 10.1.2.3 is a good stack ID and a good stack locator.
outside the site, it becomes simply meaningless garbage bits.

- if the site's NAT box has public address 192.0.2.1, then the stack
identified internally could be identified externally as
192.0.2.1:<some port number> and its locator would be 192.0.2.1.
The mess here is that an IP address is no longer sufficient as a
stack identifier, and of course the port number is only borrowed
until the NAT decides to take it away.

- if a site has a tunnelled connection to another site, it could be
(for example) that 10.1.2.3 is a good identifier on both sites (because
they have agreed administratively to divide 10/8 between them) but
the locator, as far as site B is concerned, is 192.0.2.77 (because that
happens to be the tunnel address in the B to A direction). But for
anyone else on the Internet, 192.0.2.77 is meaningless.

We could give more examples, and give IPv6 examples. But the
conclusion is inescapable: whether an IP address is an identifier,
a locator, both, or neither depends on context, and not on the
syntax or semantics of the address itself. Exactly the same applies
to prefixes.

The question that this leads to is whether the simple notion of
"locator/identifier split" is actually meaningful. Is this
context-dependence of the semantics of an IP address an
accident due to slow drift in the Internet's architecture,
or is it actually a desirable property of the namespace for
IP stacks?

To answer this, we need to identify the properties required
for a stack identifier namespace and those for a stack locator
namespace. If the required properties turn out to be orthogonal,
a simple split may be possible; if they turn out to be inseparable,
a simple split may be impossible, and the context-dependency
mentioned above may be inevitable.

     Brian

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram