We describe where the json representing a wiki page can be stored and how pages move between these stores.
> Internet addresses for pages are formed by combining Slugs with various storage indications.
Clark, 2018. Designing an Internet:
> It is generally recognized that the current approach of using IP address both as a locator and as an identifier was a poor design choice.
Mobility is the obvious justification for this conclusion. In today’s Internet, dealing with mobility is complicated by the fact that the IP address is used both for forwarding and for end-node identity. Separating these two concepts into two different data fields in the packet would allow the location field (e.g., the input to the forwarding PHB) to be changed as the mobile host moved. This division does not solve the two now separate problems: keeping the location information up-to-date and making sure the identity information is not forged. Linking identity to location provides a weak form of security: if two machines have successfully exchanged packets, the location is sufficiently unforgeable that it can stand as a weak identifier, but by separating the two problems, each can be resolved separately and managed differently in different situations as circumstances require.
An alternative design approach might result in two fields, or perhaps three, each serving a distinct purpose.
* Locator: This field is used as input to the forwarding PHB of a router. For example, it may be rewritten (as in a NAT device) or be highly dynamic (in the case of a mobile device).
* End-node identifier (EID): This field is used by each end of the connection to identify itself to the other end(s). There are in general three issues with such a field: how to make sure a malicious sender cannot forge a false identifier, how each end associates meaning with this field (is there some sort of initial exchange of credentials associated with the EID, or do high-level protocols associate some meaning with it once the connection is in place?), and whether elements other than the end nodes (e.g., PHBs in the network) should be allowed to see and exploit this value.
* In-network identifier (INID): If the EID is private to the end nodes of a connection, then an architecture might define some other identifier that can be seen and used by PHBs in the path from the sender to the receivers, perhaps to support accounting or authorization for enhanced services. This possibility in turn raises many subquestions, such as how the INID is obtained, whether there are security issues associated with its use, and the the duration for which it is valid.
So while the general idea of the locator-identity split is well-understood, there is no clear agreement on how to design the system that results. Most of the architectures that David D. Clark will discuss in chapter 7 (Alternative Network Architectures) implement some sort of location-identity split and illustrate the range of approaches that have been taken to address this issue.