Re: [RRG] On identifiers, was: Re: Does every host need a FQDN

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

...
> Let's inventory what we need identifiers for:
> 
> 1. demultiplexing
> 2. access control
> 3. error detection
> 4. referrals

What about session labels, e.g. for security associations? That
is more than demultiplexing.

What about multipath management? Again, that seems more than
just demultiplexing.

> 
> And what we need locators for:
> 
> 5. forwarding packets
> 6. sending back control messages
> 
> Note that all of these uses of identifiers can be limited to the
> application or session layers so there is no need for identifiers to
> appear in any layer 3 or 4 headers - 

True, but they will "appear" invisibly in transport and cryptographic
checksums. Decoupling these from locator-addresses seems to be
a feature (among other things, it makes NAT transparent to checksums).

> if we don't mind changing
> applications and APIs to map application layer identifiers to transport
> and lower layer locators.
> 
> But changing applications is a non-starter, because the number of
> applications is so huge and application writers simply lack the
> knowledge to interact with the network properly. After 10 years there
> are still applications that don't know how to work over IPv6, for instance.
> 
> Now NOT changing applications means that the identifiers must look a lot
> like regular IP addresses. 

More precisely, it means we can't change the socket API, so I think
a shim in the socket layer may be the way to go.

   Brian


> With shim6, we avoided a mapping system at
> significant cost: we need assistence from applications when the
> initially chosen identifier is not currently a reachable locator. Also,
> shim6 feedback indicates that a pure host solution is not what most
> people want, and requiring changes on both ends is a big deployment
> barrier.
> 
> If we want to do all of this in middleboxes we pretty much end up in
> LISP territory. The data plane issues with that are fairly well
> understood by now, but this requires a identifier-to-locator mapping
> service, which is not that well understood currently.
> 
> Do we have consensus yet on what would be the best place to solve the
> problem?
> 
> -- 
> to unsubscribe send a message to rrg-request@psg.com with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
> 

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg