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

[Peter Sherbin <[e-mail]>]

> 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  

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


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

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