2.5.2 Host Identity Protocol (HIPRG)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Current Meeting Report

IETF-62 HIP RG minutes

Host Identity Protocol Research Group (HIP RG)

These are the informal minutes for the Host Identity Protocol Research Group (HIP RG) meeting, held after the 62nd IETF meeting on Friday, March 11, at Minneapolis Hilton. Thanks to Mika Kousa for his notes, on which these minutes are partially based on. Note that these minutes do not follow the typical IETF minutes format, transcribing the discussion, but are on a more superficial level.

There were three major topics discussed in the meeting:

NAT and middlebox traversal

A major part of the discussion went, once again, clarifying the difference between the two fundamentally separate approaches to NATs:

  • Firstly, HIP seems to have some potential in integrating NATs and firewalls into the architecture, making them and other similar middle boxes as first class citizens. Furthermore, it looks like that this can be done without violating or compromising the end-to-end principle, at least too much; in other words, the design of HIP allows the end-to-end HIP signalling messages to be inspected by middle boxes, allowing the middle boxes to do whatever they need to do.

    This approach is sometimes called architected NAT, or SPI-NAT.

  • Secondly, as discussed and more-or-less decided at the November Washington DC workshop and RG meeting, it looks desirable to make HIP to work with current legacy NATs. There are multiple ways of doing this. Some people prefer to run HIP over IPv6, and then let any IPv6 tunneling thing (Teredo etc) to deal with NATs. Other people would prefer to be able to run HIP natively through NATs; the PATH work is aiming for this.

    This approach is usually called legacy NAT traversal.

Even though there seems to be some controversy on what is the best way of dealing with legacy NATs with HIP, it looks best to continue in parallel on multiple fronts. Many people felt that the PATH work is important and worth doing, and a potential WG item at next rechartering. Some people would prefer to go the IPv6 way. The best option would most probably be if both are implemented and tested in practise. That would give information on how best go forward.

It was decided to adopt draft-stiemerling-hip-nat-03.txt as a research group work item, on the condition that a section clearly explaining the applicability of the draft is added.

API and upper layer identifier issues

In the API discussion covered varied ground from Miika Komu's update on his Native HIP API to Pekka Nikander's new ideas on how to integrate Service and perhaps also Session identifiers on the top of HIP. Much of the more recent work is based on the idea of delegation; for example, service identifiers, network mobility, and application mobility all need delegation as a basic component.

One additional half-baked conclusion from the discussion was that adding a true host-layer to the stack seems to necessicate relocating much of the transport layer functionality, including congestion control. It also looks like that the ideas about sessions and their properties should be given weight in future research.

Updates on on-going HIP-related projects

This part of the meeting mostly conveyed information about ongoing efforts, including the InfraHIP, Ambient Networks, and the Boeing Secure Mobile Architecture (SMA) projects. See the slides for more information.


Preferred Alternatives for Tunnelling HIP
NAT and Firewall Traversal for HIP
Middlebox Traversal Issues of HIP Communication
Native HIP API
Upper Layer Identifiers
Naming, Identities and Locators in Ambient Networks
HIP-based implementation of Secure Mobile Architecture (SMA)
Infrastructure Support for Host Identity Protocol