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

["Bound, Jim" <[e-mail]>]

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:[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