The current Internet architecture is based on using IP addresses in two distinctive roles.
From the network point of view, an IP address names the current topological location of an interface by which a host is attached to the network. That is, an IP address is used as a name for the location where a specific network interface can be found. If a host moves around and attaches its network interface to a different location, the IP address associated with the interface changes. This role is often called the locator role.
From an application point of view, an IP address identifies a host. That is, an IP address is used as an identifier for the peer host. It is expected that this identifier remains stable as long as the association is active. This role is often called the identifier role.
Due to increasing mobility and multi-homing requirements, together with other issues like IPv4 address scarcity, this dual role of IP addresses is becoming problematic. The generic phenomenon was previously studied by the IRTF NameSpace Research Group (NSRG), and the questions studied there are outside of the scope of this group.
The Host Identity Protocol (HIP) has been developed alongside the IETF and the IRTF for a few years. Its development has been partially based on the discussions that took place within the NSRG. Basically, HIP is a concrete proposal for adding a new name space to the TCP/IP stack. The new name space consist of Host Identifiers, which are cryptographic public keys. The HIP architecture adds a new layer between the IP layer and the transport layer, thereby decoupling the layers from each other, and splitting the dual roles of IP addresses. When HIP is used, IP addresses function as pure locators. Instead of IP addresses, the applications use Host Identifiers to name peer hosts. More concise representations of Host Identifiers – 128-bit Host Identity Tags (HITs) and 32-bit Local Scope Identifiers (LSIs) – have been defined to represent host identities in IPv6- or IPv4-sized address structures, respectively, allowing most, but not all, legacy applications to work unmodified on top of HIP.
The IETF Host Identity Protocol working group has been chartered to complete the short term engineering work on HIP, including the base protocol specification, basic mobility & multi-homing, basic rendezvous service, and the basic DNS records needed to store HIP related information.
The primary goal of the Host Identity Protocol Research Group (HIPRG) is to study the proposed Host Identity Protocol and architecture, including potential effects on the Internet. When indicated by its studies, the HIPRG can suggest extensions and modifications to the protocol and architecture. It is also in scope for the HIPRG to study, in a wider sense, the consequences and effects that wide-scale adoption of any type of separation of the identifier and locator roles of IP addresses is likely to have. With regard to this latter, the HIPRG is tasked with producing an experiment report providing input to the IETF on mechanisms for separating the identifier and locator nature of IP addresses. That is, given the assumption that some kind of identifier and locator separation should be adopted, the HIPRG will provide an analysis on baseline architectures and mechanisms upon which standardizing such a separation could be based.
The question of whether the basic identifier/locator split assumption is valid falls beyond the scope of the HIPRG. The group’s work is based on the assumption that such a separation is needed in one form or another, and the group must not spend excessive time discussing whether such a separation of roles is needed or not. On the other hand, it is fine to discuss the technical drawbacks that such a separation might have and ways to ameliorate these.
Within the primary guildelines discussed above, the range of topics included within the scope of the HIPRG spans:
As discussed above, the HIPRG is tasked with producing an “experiment report” documenting the collective experiences and lessons learned from other studies, related experimentation, and designs completed by the HIPRG. This might include the following:
Exploration of whether introducing an identity/locator mechanism would be architecturally sound. Since HIP and the other mechanisms propose an architectural change that is in some ways similar in scope to Network Address Translation (NAT), the consequences are far from clear. A primary task for the HIPRG is to evaluate the degree to which the result may have notable negative effects to the Internet in the large.
Does the HIP baseline architecture and protocol, or other identity/locator separation architectures, need any changes? The initial HIP specifications, produced by the HIP WG, are Experimental RFCs. The same is likely to be true for any other serious proposal for identity/locator separation. A primary task for the HIPRG is to evaluate if and what kind of changes would be needed or desirable to these initial specifications.
An initial version of the experiment report is targeted for the second quarter of 2005, and the final version for the second quarter of 2006.
The HIPRG operates in an open fashion (meetings & mailing list), though may occasionally form closed subgroups to facilitate the development of specific work items.
This Research Group has concluded and is no longer active.
The charter and other information on this page is provided as a record of history. Email addresses and links may no longer function.
For inquiries about this former Research Group, please email email@example.com.
The HIPRG concluded its work on 2012-7-24.
Additional HIPRG information is (or was) available at https://trac.tools.ietf.org/group/irtf/trac/wiki/hiprg.