draft-ietf-hip-mm-05,  Section 1:

    Finally, making
   underlying IP mobility transparent to the transport layer has
   implications on the proper response of transport congestion control,
   path MTU selection, and QoS.  Transport-layer mobility triggers, and
   the proper transport response to a HIP mobility or multihoming
   address change, are outside the scope of this document.

This is a important issue with mobility. I expect that there are some real considerations and hopefully solutions on this if and when HIP goes from experimental to standards track. But I do understand that it is likely to requrie also work on the transport side.

  It is possible to run vanilla IPsec and HIP on the same node and get
  the intended security services applied to the intended traffic if one
  is careful about configuration.  The security services are present,
  and it appears to be possible to use a HIP-unaware IPsec to do the HIP
  ESP processing.  One should worry about whether there is a possibility
  of a HIT conflicting with an actual IPv6 address as the technique
  advocated for a HIP-unaware IPsec implementation apparently has HITs
  masquerade as IPv6 addresses for IPsec processing.

  Since HIP and IPsec share a common SPI space, and traffic on any HIP
  SPI completely bypasses IPsec policy.  (Think about Steve Kent's usual
  rant about IPsec being more than just a means to apply cryptographic
  security mechanisms to traffic.)  The assurances that IPsec provides
  are easily broken with HIP, since inbound HIP traffic bypasses the
  IPsec SPD and gets handed directly to HIP, which logically has its
  own SPD.

  It is not clear to me exactly how to avoid this situation, or what to
  add to the document to warn about this security consideration.  A
  long discussion may be needed.  Since the document is intended for
  Experimental RFC, this may be an acceptable situation, but this must
  be resolved for this document to transition to the standards track.