Re: [Hipsec] RE: Updated HIP mobility & multi-homing draft

[Brian E Carpenter <brc@zurich.ibm.com>]

Just a few questions and comments (Hipsec list not copied)...

> 1. Introduction
> 
>    This document specifies an extension to the Host Identity Protocol
>    [3] (HIP). The extension provides a simple and efficient means for
>    hosts to keep their communications on-going while having multiple IP
>    addresses, either at the same time or one after another.  That is,
>    the extension provides basic support for multi-homing, mobility, and
>    simultaneous multi-homing and mobility. Additionally, the extension
>    allows communications to continue even when multi-homing or mobility
>    causes a change of the IP version that is available in the network;
>    that is, if one of the communicating hosts has both IPv4 and IPv6
>    connectivity, either directly or through a proxy,the other host can
>    alternate between IPv4 and IPv6 without any effects on the upper
>    layer protocols.

The last phrase isn't strictly true IMHO. If a change of path changes
the MTU or the QoS, this can have an effect on the ULP, especially for
real time applications.

> 4.1 End-host mobility
...
>            The upper
>    layer protocols need to know about the address and connectivity
>    change only for QoS and other similar purposes.  

Not necessarily. The QoS management system may need to know, depending
on the QoS mechanisms in use - and that is a control plane, not a
ULP.

> 5.1 Informing the peer about multiple or changed address(es)
> 
>    This document specifies a new HIP protocol parameter, the REA
>    parameter (see Section 7.1), that allows the hosts to exchange
>    information about their IP address(es), and any changes in their
>    address(es).  The logical structure created with REA parameters has
>    three levels: hosts, interfaces, and addresses.  This is illustrated
>    in Figure 1.
> 
>    			     address11
>    			   /
>    		interface1 - address12
>    	      /
>    	     /               address21
>    	host -- interface2 <
>    	     \               address22
>    	      \
>    		interface3 - address31
>    			   \
>    			     address32
> 
>                                 Figure 1

Hmm. I find the whole treatment of "interfaces" confusing. As you describe
them, they don't correspond to physical interfaces or to virtual interfaces
such as tunnel end points. They are only collections of addresses, which
you choose to group for SPI purposes. That may or may not be a useful thing,
but it would be much less confusing to use a different word instead
of overloading "interface."

...
>   Note,
>    however, that especially in the case of site multi-homing one of the
>    addresses may become unreachablewhile the other one still works.  In
>    the typical case, however, this does not require the host to inform
>    its peers about the situation, since even the non-working address
>    still logically exists.

It's just as well you don't require this notification. The last node to
know that an address is unreachable is the node that address belongs to.
Unreachability is discovered at the other end of the multihomed
session.

> 6. Protocol overview
> 
>    The readdressing protocol is designed to be piggybacked on a number
>    of existing HIP exchanges.  The main packets on which the REA
>    parameters are expected to be carried on are New SPI (NES) packets.
>    However, some implementations may want to experiment with sending REA
>    parameters also on other packets, such as R1 and I2.
> 
>    The protocol is an asymmetric protcool where one host, called the
>    Mobile Host, informs another host, called the Peer host, about
>    changes of IP addresses on one of its interfaces.  

That doesn't help with multihoming, since the host doesn't know about
its own address changes due to sudden unreachability.

  Brian