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

["Don Fedyk" <[e-mail]>]

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 
 

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]] 
> Sent: Tuesday, January 09, 2007 10:07 AM
> To: [e-mail]
> 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
> 
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ram
> 

_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram