Host Identity Protocol (hip)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional HIP Web Page

Last Modified: 2007-09-26

Additional information is available at tools.ietf.org/wg/hip

Chair(s):

  • David Ward <dward@cisco.com>

  • Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>

    Internet Area Director(s):

  • Jari Arkko <jari.arkko@piuha.net>
  • Mark Townsley <townsley@cisco.com>

    Internet Area Advisor:

  • Mark Townsley <townsley@cisco.com>

    Mailing Lists:

    General Discussion: hipsec@ietf.org
    To Subscribe: http://www1.ietf.org/mailman/listinfo/hipsec
    Archive: http://www.ietf.org/mail-archive/web/hipsec/index.html

    Description of Working Group:

    The Host Identity Protocol (HIP) provides a method of
    separating the end-point identifier and locator roles of
    IP addresses. It introduces a new Host Identity (HI)
    name space, based on public keys. The public keys are
    typically, but not necessarily, self generated.

    The specifications for the architecture and protocol
    details for these mechanisms consist of:

            draft-moskowitz-hip-arch-05.txt (at RFC editor) and
            draft-moskowitz-hip-08.txt (soon -09.txt)

    There are five publicly known, interoperating
    implementations, some of which are open source.

    Currently, the HIP base protocol works well with any pair
    of co-operating end-hosts. However, to be more useful
    and more widely deployable, HIP needs some support from
    the existing infrastructure, including the DNS, and a new
    piece of infrastructure, called the HIP rendezvous
    server.

    +-------------------------------------------------------+
    | The purpose of this Working Group is to define the    |
    | minimal infrastructure elements that are needed for  |
    | HIP experimentation on a wide scale.                  |
    +-------------------------------------------------------+

    In particular, the objective of this working group is to
    complete the base protocol specification, define one or
    more DNS resource records for storing HIP related data,
    to complete the existing work on basic mobility and
    multi-homing, and produce Experimental RFCs for these.

    Note that even though the specifications are chartered
    for Experimental, it is understood that their quality and
    security properties should match the standards track
    requirements. The main purpose for producing
    Experimental documents instead of standards track ones
    are the unknown effects that the mechanisms may have on
    applications and on the Internet in the large.

    It is expected that there will be a roughly parallel,
    though perhaps considerably broader, IRTF Research Group
    that will include efforts both on developing the more
    forward looking aspects of the HIP architecture and on
    exploring the effects that HIP may have on the applications
    and the Internet.

    The following are charter items for the working group:

    1) Complete the HIP base protocol specification.
      Starting point: draft-moskowitz-hip-08.txt (or newer)

    2) Complete the basic mobility and multi-homing support for HIP.
      Starting point: draft-nikander-hip-mm-01.txt (or newer)

    While this work partially overlaps the work in Mobile
    IP and Multi6 Working Groups, it is very different in
    the sense that is based on the Experimental HIP
    specification, and cannot function without it.

    3) Define one or more new DNS Resource Records for
      storing HIP related data, such as Host Identifiers and
      Host Identity Tags (HITs). This task explicitly
      excludes the task of defining reverse DNS entries
      based on HITs.

    4) Define a basic HIP rendezvous mechanism.

      A basic HIP rendezvous server allows mobile and
      non-mobile HIP hosts to register their current IP
      addresses at the server. Other hosts can then send
      the initial I1 packets to the rendezvous server, which
      forwards the packets to the HIP host's current address.

      This task explicitly excludes solving more general
      problems, such as the referral problem. Also excluded
      is the problem of finding the right rendezvous server.
      It is expected that the DNS records will be used for that.

      The Working Group bases all the work on the HIP achitecture
      specification (as defined above).

    5) Complete the HIP Architecture specification
      Starting point: draft-moskowitz-hip-arch-06.txt

    Goals and Milestones:

    Done  First version of the HIP basic mobility and multi-homing mechanism specification.
    Done  First version of the HIP DNS resource record(s) specification.
    Done  First version of the HIP basic rendezvous mechanism specification.
    Done  WGLC on the HIP architecture specification
    Done  Submit the HIP architecture specification to the IESG
    Done  WG LC on the base protocol specification
    Done  WG LC on the ESP usage specification
    Done  WGLC the HIP registration extensions specification
    Done  WGLC the HIP DNS resource record(s) specification
    Done  WG LC on the basic HIP rendezvous mechanism specification.
    Done  Submit the ESP usage specification to the IESG for Experimental
    Done  Submit the base protocol specification to the IESG for Experimental
    Done  WG LC on the HIP basic mobility and multi-homing specification.
    Done  Submit the HIP registration extensions specification for Experimental
    Done  Submit the HIP DNS resource record(s) specification to the IESG for Experimental.
    Done  Submit the HIP basic mobility and multihoming specification to the IESG for Experimental.
    Done  Submit the basic HIP rendezvous mechanism specification to the IESG for Experimental.
    Jan 2007  WGLC Legacy NAT traversal specification
    Jan 2007  WGLC Legacy Application Interworking specification
    Jan 2007  WGLC Native API specification
    Mar 2007  Submit the Legacy NAT traversal specification to the IESG
    Mar 2007  Submit the Legacy Application Interworking specification to the IESG
    Mar 2007  Submit Native API specification to the IESG
    Apr 2007  Recharter or close the WG

    Internet-Drafts:

    Basic HIP Extensions for Traversal of Network Address Translators and Firewalls (58470 bytes)
    Basic Socket Interface Extensions for Host Identity Protocol (HIP) (42383 bytes)
    Using the Host Identity Protocol with Legacy Applications (35727 bytes)

    Request For Comments:

    Host Identity Protocol (HIP) Architecture (RFC 4423) (60977 bytes)
    Host Identity Protocol (RFC 5201) (240492 bytes)
    Host Identity Protocol (HIP) Domain Name System (DNS) Extensions (RFC 5205) (34799 bytes)
    Host Identity Protocol (HIP) Registration Extension (RFC 5203) (26620 bytes)
    Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (RFC 5202) (68195 bytes)
    Host Identity Protocol (HIP) Rendezvous Extension (RFC 5204) (30233 bytes)
    End-Host Mobility and Multihoming with the Host Identity Protocol (RFC 5206) (99430 bytes)
    IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

    Return to working group directory.

    Return to IETF home page.