Internet DRAFT - draft-henderson-hip-generalize


Network Working Group                                       T. Henderson
Internet-Draft                                        The Boeing Company
Expires: August 14, 2005                               February 13, 2005

                  Generalizing the HIP base protocol

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 14, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   The Host Identity Protocol and architecture (HIP) proposes to add a
   cryptographic name space for network stack names.  This draft
   observes that HIP can be viewed as an instance of a more general
   migration towards decoupling identity from location in the Internet
   architecture, and shows how other proposals (mobile IP, multi6,
   mobike, and i3) fit into this framework.  We argue that if the HIP
   base protocol were to be slightly generalized, it might be useful to

Henderson               Expires August 14, 2005                 [Page 1]
Internet-Draft     Generalizing the HIP base protocol      February 2005

   other related efforts and might allow more experimental flexibility.
   Specifically, an extensible identifier TLV, the ability to define
   usage profiles for the HIP handshake, and a relaxation of the
   requirements that specific HIP messages carry specific parameters are
   the three changes suggested.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Taxonomy of Proposals  . . . . . . . . . . . . . . . . . . . .  5
     3.1   Examples . . . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.1   Mobile IP with Route Optimization  . . . . . . . . . .  6
       3.1.2   Host Identity Protocol . . . . . . . . . . . . . . . .  7
       3.1.3   Multihoming L3 Shim  . . . . . . . . . . . . . . . . .  7
       3.1.4   i3 (Internet Indirection Infrastructure) . . . . . . .  8
     3.2   Combinations and Syntheses . . . . . . . . . . . . . . . .  8
   4.  Implications for HIP work  . . . . . . . . . . . . . . . . . .  9
     4.1   Proposed changes to HIP  . . . . . . . . . . . . . . . . .  9
       4.1.1   Identifiers  . . . . . . . . . . . . . . . . . . . . .  9
       4.1.2   Handshake  . . . . . . . . . . . . . . . . . . . . . . 10
       4.1.3   Mandatory parameters . . . . . . . . . . . . . . . . . 10
       4.1.4   Per-packet context . . . . . . . . . . . . . . . . . . 11
     4.2   Example Uses . . . . . . . . . . . . . . . . . . . . . . . 11
       4.2.1   Securing MIPv6 Binding Update  . . . . . . . . . . . . 11
       4.2.2   Site multiHoming by IPv6 interMediation (shim6)  . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
       Intellectual Property and Copyright Statements . . . . . . . . 19

Henderson               Expires August 14, 2005                 [Page 2]
Internet-Draft     Generalizing the HIP base protocol      February 2005

1.  Introduction

   The Host Identity Protocol (HIP) [1] is an experimental effort in the
   IETF and IRTF to study a new public-key-based name space for use as
   host identifiers in Internet protocols.  Taking a step back, HIP can
   be viewed as one instance of a large number of proposals for
   decoupling (network) name or identity from (network) location in the
   Internet architecture, managing more than one IP address for active
   communications flows, or providing an additional layer of indirection
   in the protocol stack, located at or slightly above the network

   The topic of whether a new name space is needed for the Internet is
   controversial.  The Name Space Research Group (NSRG) at the IRTF was
   not able to reach consensus on the issue, nor even to publish a final
   report.  The IRTF HIP research group is tasked to evaluate the impact
   of deployment of a HIP or related name space in the Internet.  Yet,
   there seems to be little disagreement that, for many scenarios, some
   level of indirection from network name to network location is
   essential or highly desirable to provide adequate service.  Mobile IP
   [2] is one example (the first such Standards Track proposal), with
   particular deployment and security properties, that reuses an
   existing name space for host naming.  Since mobile IP was finalized
   (and in a few cases, even around or before the time it was initially
   proposed [3]), many new variants to providing this indirection have
   been suggested.

   Most recently, there has been standardization and development efforts
   in the IETF and IRTF on multi6 protocols and HIP.  In the research
   community, several related proposals have been explored, such as the
   Internet Indirection Infrastructure (i3) [4], IPNL [5], DataRouter
   [6], Network Pointers [7], FARA [8], and TRIAD [9].  The purpose of
   this draft is to outline the broad framework into which most of these
   examples fit, provide a way of categorizing the various proposals,
   and how they might be coherently combined, and discuss how the HIP
   base protocol [1]  could be generalized to better support this
   broader framework.

Henderson               Expires August 14, 2005                 [Page 3]
Internet-Draft     Generalizing the HIP base protocol      February 2005

2.  Motivation

   It is beyond the scope of this draft to discuss whether a network
   layer identifier is needed or preferred to identifiers at other
   layers, but some of the main reasons that are frequently cited in
   support of identifiers at this layer include generality, security,
   mobility, multihoming (both site and local multihoming), traversal of
   multiple addressing realms, and the enabling of network overlays.
   For more insight into the motivations of various proposals, see,
   e.g., [4], [10], [11], [12], and [8].

   The purpose of this draft is to explore the common ground of a number
   of proposals to use location-independent identifiers as part of the
   network layer (or logically or explicitly wedged between the network
   and transport layer protocols), and to describe how a more general
   HIP protocol might be of more general use.

Henderson               Expires August 14, 2005                 [Page 4]
Internet-Draft     Generalizing the HIP base protocol      February 2005

3.  Taxonomy of Proposals

   In this section, we attempt to categorize a number of proposals and
   show the overall commonality of the approach.  As examples, we will
   describe how the multi6 shim [13], mobile IP [2], HIP [1], and i3 [4]
   map into this framework.

   The following figure, adapted from [13], depicts the architecture
   under consideration (although not all proposals map exactly to this
   architecture, the diagram is conceptual).  It illustrates a placement
   of a (logical or real) shim below the IP endpoint sublayer and the IP
   routing sublayer.

                       | Transport Protocols |
                ------ ------- -------------- -------------     IP endpoint
                | AH | | ESP | | Frag/reass | | Dest opts |     sub-layer
                ------ ------- -------------- -------------
                            | Shim layer |
                                ------                         IP routing
                                | IP |                         sub-layer

   The following details are relevant to such an architecture and are
   different from traditional systems:

   Upper layer identifier: The 32- or 128-bit datum used by transport
      protocol or above (that may be different from the IP address or
      locator used at the IP routing sub-layer).  Examples include
      special IP addresses (e.g., mobile IP home address, the
      identifier-address discussed in [13], and unique-local addresses
      [14]), and host identity tags (HITs) [1], which are non-routable
      by the existing IP infrastructure.  A further distinction may be
      made between transport, session, and application-layer

   Identifier resolution: If the upper layer identifier is not routable
      or is not the same as the outer IP addresses that will appear on
      the packet, it must be resolved to a routable locator.  Proposals
      in this space are sometimes categorized as being "early binding"
      (e.g., HIT resolution on the end hosts, mobile IP with route
      optimization) or "late binding" (e.g., trigger resolution within
      the i3 infrastructure, mobile IP without route optimization).

Henderson               Expires August 14, 2005                 [Page 5]
Internet-Draft     Generalizing the HIP base protocol      February 2005

   Context establishment: When upper layer identifiers are used that are
      different from the locators, some context establishment protocol
      is likely needed to signal the upper layer identifiers in use, and
      perhaps to establish context for flow demultiplexing and other
      purposes.  The HIP base protocol is a clear example of this,
      serving to signal to the peer the upper layer HIT identifiers to
      use (and also to authenticate the host if needed), to derive
      keying material used within the protocol itself and for security
      associations, and, when ESP is used, to select SPIs.  Other
      working groups (shim6 and mobike) are poised to define their own
      context establishment protocol.

   Per-packet context tag: When identifiers and locators are different,
      some kind of context tag is needed for receivers to locate the
      right identity context for the received packet.  In HIP with ESP,
      the SPI serves as a compressed representation of the HITs; other
      tags may also be possible with HIP.  Mobile IP with route
      optimization uses Routing Headers or Destination Options for this
      purpose.  Another example is the M6 shim protocol of SIM [15].

   Locator management: The techniques by which multiple locators are
      associated with the identifier, using some security technique for
      binding, and by which locators are selected for source and
      destination addresses when there are more than one to choose from.
      Proposals in this space include MAST [16], CELP [17], multi6
      failure detection and locator selection [18], hash-based addresses
      [19], and HIP multihoming extensions [20].

3.1  Examples

   Below are some examples of how specific proposals map into the above

3.1.1  Mobile IP with Route Optimization

   Upper layer identifier: The home address serves as an upper layer

   Identifier resolution: Resolution is done at the endpoints, when the
      Care-of Address (COA) is appended (early binding).

   Context establishment: The Binding Update procedure is used to
      establish the tunneling context.

Henderson               Expires August 14, 2005                 [Page 6]
Internet-Draft     Generalizing the HIP base protocol      February 2005

   Per-packet context tag: The home address is carried in each packet,
      in either the Home Address Destination Option or the Type 2
      Routing Header.

   Locator management: New CoA locators are sent directly to the
      correspondent nodes via the Binding Update message.  The Binding
      Update is authenticated via the key generated as part of the
      return routability procedure.

3.1.2  Host Identity Protocol

   Upper layer identifier: The Host Identity Tag, a 128-bit hash of the
      public key, is used as the upper layer identifier in transport

   Identifier resolution: Early-binding; either performed via DNS
      lookup, some to-be-developed resolution service, or
      opportunistically (when the Initiator does not know the
      Responder's identity, only the address).

   Context establishment: A four-packet handshake performs a
      Diffie-Hellman key exchange and, when used with ESP, sets up the
      context for the SA.

   Per-packet context tag: The SPI in the SA serves as a compressed
      representation of the HITs in every data packet.

   Locator management: Mobility extensions to the base protocol allow IP
      addresses associated with an ESP tunnel to be added, changed, and

3.1.3  Multihoming L3 Shim

   Upper layer identifier: Some kind of IP address, although the exact
      semantics are still unsettled.

   Identifier resolution: Performed at the end-hosts (early binding).

   Context establishment: An as-yet unspecified protocol will be used to
      establish context when the upper layer identifiers in use start to
      diverge from the locators in use.

   Per-packet context tag: Options include using predefined
      relationships between identifier addresses and locator addresses,
      use of the flow label, or use of a new extension header.

Henderson               Expires August 14, 2005                 [Page 7]
Internet-Draft     Generalizing the HIP base protocol      February 2005

   Locator management: Locators may be related to each other
      cryptographically, or may be authenticated via some as-yet
      unspecified protocol.

3.1.4  i3 (Internet Indirection Infrastructure)

   Upper layer identifier: The i3 tag.

   Identifier resolution: Performed in the i3 forwarding infrastructure,
      since the act of sending and receiving packets is decoupled (late

   Context establishment: Directives for receiving packets sent to
      particular tags are explicitly inserted into the forwarding
      infrastructure by receiving hosts; no end-to-end context need be

   Per-packet context tag: Explicitly inserted in the IP packet: [IP |
      UDP | trigger stack | transport data].

   Locator management: Locator management is handled by receivers and
      their interactions with the forwarding infrastructure.

3.2  Combinations and Syntheses

   Not surprisingly, a large number of variants and combinations of the
   above have been proposed, to aggregate the desirable properties of
   distinct proposals.  For example, we have:
   o  HIP/i3:  The Host Identity Indirection Infrastructure (Hi3),
      advocated as a means of securing i3 with the HIP protocol [21];
   o  HIP/IKE:  Proposal to use IKEv2 as the control plane for HIP [22];
   o  HIP/mobile IP:  As presently defined, Mobile IP with Route
      Optimization resembles HIP mobility.  It has been suggested that
      HIP could be used to secure the route optimization of mobile IPv6;
   o  HIP/multi6:  A lighter-weight variant of HIP was proposed, to
      address the concerns of HIP's requirement for public-key
      operations and the need to manage a new name space [23];
   o  MOBIKE:  Working group defining mobility enhancements to IKEv2
      that will allow SAs to persist across locator changes [24]; and
   o  HIP Rendezvous Server (RVS):  The HIP RVS is evolving to resemble
      a combination of a mobile IP home agent and a STUN [25] server.
   Our conjecture is that a generalized HIP protocol may make some of
   these combinations easier, as exemplified in Section 4.2 below.

Henderson               Expires August 14, 2005                 [Page 8]
Internet-Draft     Generalizing the HIP base protocol      February 2005

4.  Implications for HIP work

   It seems wasteful to this author for so many experimental and early
   standardization efforts to be designing to similar goals yet arriving
   at slightly different protocol solutions.  Given that HIP is an
   experimental effort, and that the overall acceptance of the
   architecture and its implications is still an open question, it is
   worth considering whether there are protocol or architectural
   elements of the above taxonomy that could be generalized in HIP, to
   allow a greater breadth of experimentation and future flexibility.
   If the HIP protocol elements were more modular, HIP-based protocols
   might be more useful to many of these efforts.  In that sense, we
   should explore whether the currently proposed HIP protocol can be
   handled as a particular usage profile of a more general architecture.
   Note that recent decisions in the HIP working group to decouple ESP
   from the base protocol are an initial step in this direction.

4.1  Proposed changes to HIP

   The following changes would make HIP more flexible, at the expense of
   slightly more per-packet overhead in the protocol.  The existing HIP
   could be mapped directly to the below as a specific usage profile.

4.1.1  Identifiers

   Allow the use of non-128-bit and non-HIT identifiers.  For example,
   the initial locators might be used as the upper layer identifiers, or
   some other flat name (other than HIT).  In addition, we should
   consider whether larger than 128-bit HITs may be needed in the future
   for HIP.  If in the HIP header, a TLV were used instead of the bare
   128-bit HITs, the context establishment protocol may be useful for
   other non-HIP uses.

   Thus, the HIP header would look like:

Henderson               Expires August 14, 2005                 [Page 9]
Internet-Draft     Generalizing the HIP base protocol      February 2005

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   | Next Header   |  Payload Len  |     Type      |  VER. |  RES. |
   |          Controls             |           Checksum            |
   |             Type              |             Length            |
   |                Sender's Upper Layer Identifier (e.g., HIT)    |
   |                                                               |
   |                                                               |
   |                                                               |
   |             Type              |             Length            |
   |               Receiver's Upper Layer Identifier               |
   |                                                               |
   |                                                               |
   |                                                               |

4.1.2  Handshake

   The existing HIP handshake (I1 through R2) is based on the SIGMA
   family of key-exchange protocols [26] and should continue to be the
   basis for the context handshake for the existing HIP usage profile,
   but there should also be other possibilities allowed, especially for
   impoverished devices that are willing to trade some security for less
   computation (public key signatures).  The multi6 WIMP proposal based
   on hash chains [27] is one such alternative context-establishment
   handshake.  One way to potentially support multiple protocol
   semantics would be to support a handshake-type parameter in the I1.
   The R1 could accept or reply with a list of handshake-types that it
   supports (i.e., similar to how the HIP- and ESP-TRANSFORM are
   negotiated today).  An alternative to another TLV that saves bits but
   is less flexible is to use some of the HIP Control bits.  The
   handshake could also potentially be delayed, such as in the multi6
   shim proposals (in which one possible use case is to avoid performing
   any context handshake until a locator set has to change).

4.1.3  Mandatory parameters

   There should be very few mandatory parameters for a given HIP packet
   type, in general.  However, for a specific usage profile, there will
   be mandatory parameters.  For example, when using the current HIP

Henderson               Expires August 14, 2005                [Page 10]
Internet-Draft     Generalizing the HIP base protocol      February 2005

   profile, R1 MUST contain PUZZLE, but not necessarily when using
   another profile.  The main mandatory parameters are the identifier
   TLVs discussed above in Section 4.1.1, which are always the first two
   parameters in the HIP header.  The HIP base protocol specification
   should not include statements such as making ESP mandatory for a HIP

4.1.4  Per-packet context

   This step (towards more flexibility) has already been agreed upon by
   the working group, allowing ESP to be one of potentially other
   per-packet contexts used with HIP (including possibly SRTP [29] or
   another shim header such as the M6 header proposed in SIM [15]).

4.2  Example Uses

   Presently, the HIP drafts are being reworked and extended to cover
   NAT traversal and middlebox registration issues.  The extensions will
   be based on established techniques including STUN [25], and MIDCOM
   and NSIS WG work.  If a generalized HIP protocol were available and
   had solved all of these issues, they may apply more generally to
   other protocol efforts.  For example, NAT traversal techniques could
   perhaps be common across multiple protocols.

   Likewise, there are probably techniques in use in other protocols
   that could be leveraged in the generalized HIP.  For example,
   micromobility extensions to mobile IP could be folded into a general
   framework and made to apply to non-mobile-IP mobility as well.

4.2.1  Securing MIPv6 Binding Update

   One security aspect of Mobile IPv6 is that, while the mobile host can
   be assumed to have a security relationship (shared secret) with the
   home agent, it has no such assurance with an arbitrary correspondent
   node.  This has made securing the mobile IPv6 route optimization
   mechanism more involved.

   Presently, a mobile host using Mobile IPv6 can elect to send a
   Binding Update to any correspondent node that implements the
   extensions.  Prior to the binding update, a return routability check
   through the home network is needed to create a binding management key
   (Kbm).  This binding management key does not have persistence across
   mobile node readdressing.

   An alternative may be to use the Diffie Hellman key exchange defined
   in the HIP base protocol to create keying material to authenticate
   binding updates, and to use the HIP mobility management technique
   (UPDATE/UPDATE ACK and address check) to authenticate via a keyed

Henderson               Expires August 14, 2005                [Page 11]
Internet-Draft     Generalizing the HIP base protocol      February 2005

   MAC.  For example, the mobile node could initiate a "mobile IP-based"
   HIP exchange with the correspondent node using its home address as
   the source upper layer identifier, the correspondent node's IP
   address as the destination upper layer identifier, and some parameter
   or control bit to declare that the HIP I1 has "mobile IP" semantics.
   The client puzzle and nonce could be optionally included in the HIP
   R1, DIFFIE_HELLMAN would be mandatory, and signatures would be
   optional (variants could be defined that still used public keys for
   authentication if desired, and allowed their inclusion as additional
   HIP parameters).

   One possible benefit of the above is that it more closely aligns with
   the presently defined mobile IPv6-- the handshake can be deferred
   (initiated, perhaps, only before a mobile node is ready to move), and
   there is no reliance on public key operations, although there is a
   path forward to add such if so desired.  Use of a home agent becomes
   optional (via HIP rendezvous server).  The overall approach provides
   a possible migration path from an enhanced mobile-IP-based solution
   (which does not require new name space management) to public-key
   based extensions that may (HIP backed up by PKI or certificates) or
   may not (opportunistic HIP, or Purpose-Built Keys) involve strong
   identity authentication.

4.2.2  Site multiHoming by IPv6 interMediation (shim6)

   The shim6 WG is expected to be chartered to produce an IPv6 site
   multihoming solution based on a specific network layer shim
   architecture.  The overall approach is discussed in a recent multi6
   draft "Multihoming L3 Shim Approach" [13].  Some features of this
   solution have already been defined by the multi6 design team (e.g.,
   hash-based addresses) [19], while other elements such as the context
   management protocol are still unspecified.  Some goals stated in [13]
   are to use routable IP locators as the upper layer identifiers, and
   to permit context establishment to be deferred or to occur
   asynchronously with data packets.

   The multi6 functional decomposition [10] describes a number of
   functions that could potentially be met by a generalized HIP protocol
   that used routable IP addresses (or even centrally-assigned unique
   local addresses [28]) as upper layer identifiers.  Specifically, the
   identified M6 host-pair establishment exchange:

Henderson               Expires August 14, 2005                [Page 12]
Internet-Draft     Generalizing the HIP base protocol      February 2005

      Initiator                  Receiver
        |        P1                 |
        |        P2                 |
        |        P3                 |
        |        P4                 |

   could be supported by a generalized HIP that allowed for non-HIT
   identifiers, and alternatives for shared secret generation (e.g.,
   hash chains such as described in WIMP-F [27] could be defined for
   such a usage profile).  Additionally, it seems that if locator set
   management techniques (Section 4 of [10]) are to be developed as part
   of the shim6 solution, such techniques should be reused and not
   reinvented by HIP.

Henderson               Expires August 14, 2005                [Page 13]
Internet-Draft     Generalizing the HIP base protocol      February 2005

5.  Security Considerations

   There are clearly security issues related to mixing and matching
   protocol elements, in terms of potentially weakening security
   properties of a given protocol such as HIP.  However, we do not
   address the security properties of any particular usage profile
   supported by a more generalized protocol, but leave that instead for
   other drafts.

Henderson               Expires August 14, 2005                [Page 14]
Internet-Draft     Generalizing the HIP base protocol      February 2005

6.  IANA Considerations

   No specific proposals in this draft.

Henderson               Expires August 14, 2005                [Page 15]
Internet-Draft     Generalizing the HIP base protocol      February 2005

7.  Acknowledgments

   Jeff Ahrenholz, Pekka Nikander, and Jukka Ylitalo provided comments
   on an earlier version of this draft.

8  References

   [1]   Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-01
         (work in progress), October 2004.

   [2]   Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

   [3]   Castineyra, I., Chiappa, N. and M. Steenstrup, "The Nimrod
         Routing Architecture", RFC 1992, August 1996.

   [4]   Stoica, I., Adkins, D., Zhuang, S., Shenker, S. and S. Surana,
         "Internet Indirection Infrastructure (i3)",  Proceedings of ACM
         SIGCOMM, August 2002.

   [5]   Francis, P. and R. Gummadi, "IPNL:  A NAT-Extended Internet
         Architecture",  Proceedings of ACM Sigcomm Conference, August

   [6]   Touch, J. and V. Pingali, "DataRouter:  A Network-Layer Service
         for Application-Layer Forwarding",  Proceedings of
         International Workshop on Active Networks (IWAN), December

   [7]   Tschudin, C. and R. Gold, "Network Pointers",  ACM Computer
         Communications Review, January 2003.

   [8]   Clark, D., Braden, R., Falk, A. and V. Pingali, "FARA:
         Reorganizing the Addressing Architecture",  Proceedings of ACM
         SIGCOMM FDNA Workshop, August 2003.

   [9]   Cheriton, D. and M. Gritter, "TRIAD:  A New Next-Generation
         Internet Architecture",  Unpublished, available at Citeseer,
         July 2000.

   [10]  Bagnulo, M. and J. Arkko, "Functional decomposition of the M6
         protocol", draft-ietf-multi6-functional-dec-00 (work in
         progress), December 2004.

   [11]  Moskowitz, R., "Host Identity Protocol Architecture",
         draft-ietf-hip-arch-02 (work in progress), January 2005.

   [12]  Balakrishnan, H., Lakshminarayanan, K., Ratnasamy, S., Shenker,

Henderson               Expires August 14, 2005                [Page 16]
Internet-Draft     Generalizing the HIP base protocol      February 2005

         S., Stoica, I. and M. Walfish, "A Layered Naming Architecture
         for the Internet",  Proceedings of ACM SIGCOMM, August 2004.

   [13]  Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach",
         draft-ietf-multi6-l3shim-00 (work in progress), January 2005.

   [14]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
         Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
         progress), January 2005.

   [15]  Nordmark, E., "Strong Identity Multihoming using 128 bit
         Identifiers (SIM/CBID128)", draft-nordmark-multi6-sim-01 (work
         in progress), October 2003.

         EXTENDED PROPOSAL", draft-crocker-mast-proposal-01 (work in
         progress), September 2003.

   [17]  Crocker, D., "Framework for Common Endpoint Locator Pools",
         draft-crocker-celp-00 (work in progress), February 2004.

   [18]  Arkko, J., "Failure Detection and Locator Selection in Multi6",
         draft-arkko-multi6dt-failure-detection-00 (work in progress),
         October 2004.

   [19]  Bagnulo, M., "Hash Based Addresses (HBA)",
         draft-ietf-multi6-hba-00 (work in progress), December 2004.

   [20]  Nikander, P., "End-Host Mobility and Multi-Homing with Host
         Identity Protocol", draft-ietf-hip-mm-00 (work in progress),
         October 2004.

   [21]  Nikander, P., "Host Identity Indirection Infrastructure (Hi3)",
         draft-nikander-hiprg-hi3-00 (work in progress), June 2004.

   [22]  Yan, R., "A proposal to replace HIP base exchange with IKE-H
         method", draft-yan-hip-ike-h-00 (work in progress), November

   [23]  Nikander, P., "Considerations on HIP based IPv6 multi-homing",
         draft-nikander-multi6-hip-01 (work in progress), July 2004.

   [24]  Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol",
         draft-ietf-mobike-design-01 (work in progress), January 2005.

   [25]  Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
         Simple Traversal of User Datagram Protocol (UDP) Through
         Network Address Translators (NATs)", RFC 3489, March 2003.

Henderson               Expires August 14, 2005                [Page 17]
Internet-Draft     Generalizing the HIP base protocol      February 2005

   [26]  Krawczyk, H., "The IKE-SIGMA Protocol",
         draft-krawczyk-ipsec-ike-sigma-00 (work in progress), November

   [27]  Ylitalo, J., "Weak Identifier Multihoming Protocol (WIMP)",
         draft-ylitalo-multi6-wimp-01 (work in progress), July 2004.

   [28]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
         Addresses", draft-hinden-ipv6-global-local-addr-02 (work in
         progress), July 2003.

   [29]  Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K.
         Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
         3711, March 2004.

Author's Address

   Tom Henderson
   The Boeing Company
   P.O. Box 3707
   Seattle, WA


Henderson               Expires August 14, 2005                [Page 18]
Internet-Draft     Generalizing the HIP base protocol      February 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Henderson               Expires August 14, 2005                [Page 19]