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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Jan 2004 16:16:11 +0100

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

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 14 Jan 2004 17:59:35 +0100

Brian,

Thanks a lot on your comments.

>>                                 ... the other host can

I changed this to read:

                                     ... the other host can alternate
       between IPv4 and IPv6, without needing to tear down and
       re-establish upper layer protocol connections or associations.
       In other words, the way upper layer protocols need to react to
       cross-IP-version handovers does not differ from the way they
       needs to react intra-IP-version handovers.

Better?

> on the QoS mechanisms in use - and that is a control plane, not a

I'm afraid I don't quite understand your comment.  Anyway, I changed
the text to read

                                The upper layer protocols do not
         need to know about the address and connectivity change
         but perhaps to react to changed QoS, MTU, or for other
         similar purposes.  In most cases, they do not need to
         know.

Any better?

> of overloading "interface."

I changed the term to "Address Group", and updated the rest of the
spec accordingly.

> Unreachability is discovered at the other end of the multihomed

Thanks.  I'll try to note this in the other draft; I don't see how
this would be formulated here.

>>    of existing HIP exchanges. ...
>>

While I agree with your comment, I'm afraid I don't quite see the
point.  The assumption is that the HIP hosts announce their
multi-homing situation as soon as they create HIP associations,
modulo possible privacy and policy concerns.  Hence, when a host
becomes unreachable through one of its addresses, its peers already
know about the other potential addresses.

Should I discuss this in the forthcoming -nikander-multi6-hip-
draft?

Section 8.4 Changing the preferred address mentions that:

>    A host MAY want to change the preferred outgoing address for many
>    reasons, e.g., because traffic information or ICMP error messages
>    indicate that the currently used preferred address may have become

That is meant to cover the case where ULP information, such as TCP
timeouts, indicate that the preferred address needs to be changed.
But maybe the term "traffic information" is inaccurate and should be
replaced with something better.  Any suggestions?

--Pekka

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jan 2004 22:21:48 +0100

Pekka,

>        needs to react intra-IP-version handovers.

Fine, thanks

>          similar purposes.  In most cases, they do not need to

That is fine. What I meant is that in many implementations of diffserv QOS,
the socket user knows nothing about it - a QOS manager of some kind is
strapped onto the side of the IP stack and directs the IP stack to apply 
different diffserv treatments to different sockets. And actually when
the path changes the QOS manager may well care (because different paths may
have different QOS capabilities).

> I changed the term to "Address Group", and updated the rest of the

Yes, I really find that much clearer.

> know about the other potential addresses.

OK, maybe I read your text too quickly. In general multi6 needs to think
a bit about what actually triggers a multihoming switch.

> Should I discuss this in the forthcoming -nikander-multi6-hip-

Yes, I think it fits there.

> replaced with something better.  Any suggestions?

At this stage I would stick to something quite general. This is going to
be a question for all solutions, I think.

Regards
   Brian