Subject: [RAM] Thoughts about context-dependency of id/loc semantics (long)

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Jan 2007 16:06:39 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 9 Jan 2007 15:35:38 -0500

Brian, excellent analysis.  I feel we need to answer your question below
before we go much further down the path here. 

Thank You,
/jim

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Tuesday, January 09, 2007 10:07 AM
> To: [email-masked]
> Subject: [RAM] Thoughts about context-dependency of id/loc 
> semantics (long)
> 
> 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
> 
> But it turns out that 'example.com' (which in the original 
> concept of DNS would have identified a specific interface on 
> a specific
> 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".
> 
> 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
> 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.
> 
> 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:
> 
> - 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.
> 
> 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 
> accident due to slow drift in the Internet's architecture, or 
> is it actually a desirable property of the namespace for IP stacks?
> 
> 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
>

---

From: Peter Sherbin <[email-masked]>
Date: Tue, 9 Jan 2007 17:01:38 -0800 (PST)

> an IP address... can be a... identifier, a locator, neither, or both *depending on

> context*.

A name tells what the thing is. A name is a quality of the thing.
A location tells where the thing is. A location is a quality outside of the thing.
Hence an IP address can be an identifier, a locator or neither.
An IP address can not be both regardless of the context.

> The question... is whether the simple notion of "locator/identifier split" is
actually meaningful.

Such split would be natural. Any attempt to combine both is meaningless.

> Is this context-dependence of the semantics of an IP address an accident..., or is

> it actually a desirable property of the namespace for IP stacks?

IP address semantics matter as long as the unrelated mean serves the purpose. Sound
architecture would follow natural relationships.

Thanks,

Peter  

> > context-dependency mentioned above may be inevitable.

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

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 10 Jan 2007 11:25:04 -0500

Hi Brian

Nice Summary
Then is "addressing" in addition to 

-Identifying something
-Locating something 

Also equally required to be
- Capable of being symmetrically translated between contexts? 

The better translation is supported by underlying protocol(s,) the
easier it is to make contexts "well formed" and capable of supporting
mobility.

Regards,
Don 

> are conceptually
> DNS took care
> change ISPs,
> routing system

---

From: [email-masked]
Date: Tue, 16 Jan 2007 19:14:05 +0100

Brian,

See my comments below.

> anyone else on the Internet, 192.0.2.77 is meaningless.

Your three examples are a consequence of RFC1918. NAT and tunnels
could have been deployed even if private addresses didn't exist
to hide for example a part of an enterprise network. But it was
RFC1918 which introduced a new context of interpretation for IP
addresses. And so it did RFC1112 where IP multicast addresses
were introduced. This partition of the address space implies
new contexts of interpretations. An example of this is an
enterprise network where 10/8 is not only meaningful but also
a network in which private prefixes and public prefixes can
share the same routing table, and both can be identifiers
and locators.

> syntax or semantics of the address itself. Exactly the same applies

Yes, but we can also think on specific prefixes that could
be only used as locators for example.

> "locator/identifier split" is actually meaningful.

Yes, and I think the "loc/id split" should not be taken
as an absolute but in a relative sense: what it is an
identifier (a non-locator more precisely) at a certain
level can be perfectly used as a locator at another level.

> ................................................ Is this

The context-dependence of the semantics of an IP address
is not an accident but it is a direct consequence of
the two RFCs mentioned above. And their effect on the
interdomain routing infrastructure is so big that every
single router connecting to the Internet will have to
remove for example private prefixes from the BGP updates.

Semantics is always context-dependent.

> mentioned above may be inevitable.

There is another way to study this problem: we can start
with a solution that is orthogonal in a specific context
and then analyze the pros and cons of the solution.

Regards,
Juanjo