Some definitions (Was: Re: New issue 16: No packets from other end?)

Hello all,

While we have not found agreement yet, I think this is
a very useful discussion. I believe that when we come to
the conclusion we have come a long way towards agreeing
what MOBIKE protocol is...

Let me attempt a few definitions that may ease the
discussion.

Here's an overview, details at the end of the mail:
Basically, I think that we have something
called Available Addresses, delivered to MOBIKE from
IPv6/DNA etc. As far as I can see, no one in the WG
is thinking of using MOBIKE mechanisms for this.

I'd also like to distinguish between locally operational
and non-operational addresses; you can have an address
but for some reason you know that it isn't working. For
instance, the default router is down. I don't see MOBIKE
doing anything for this either, we already IPv6 and other
mechanisms for this.

Finally, what really matters for MOBIKE is an address pair, and
whether communication using that address pair is possible. This
is only possible if the two addresses are locally operational
AND there's IP connectivity between them. The latter is what we
are currently debating: do we expect the connectivity to be
tested and the best pair chosen by MOBIKE or something else?

Details:

1.  Available Addresses

    MOBIKE nodes need to be aware of what addresses they themselves have.
    If a node loses the address it is currently using for communications,
    another address must replace this address. And if a node loses an
    address that the node's peer knows about, the peer must be informed.
    Similarly, when a node acquires a new address it may generally wish
    the peer to know about it.

    Definition. Available address. An address is said to be available if
    the following conditions are fulfilled:

    o  The address has been assigned to an interface of the node.

    o  If the address is an IPv6 address, we additionally require that
       (a) the address is valid in the sense of RFC 2461, and that
       (b) the address is not tentative in the sense of RFC 2462.  In
       other words, the address assignment is complete so that
       communications can be started.

       Note this explicitly allows an address to be optimistic in the
       sense of [draft-ietf-ipv6-optimistic-dad] even though
       implementations are probably better off using other
       addresses as long as there is an alternative.

    o  The address is a global unicast or unique site-local address
       [draft-ietf-ipv6-unique-local-addr].

       That is, it is not an IPv6 link-local or site-local address.
       Where IPv4 is considered, it is not an RFC 1918 address.

    Available addresses are discovered and monitored through mechanisms
    outside the scope of MOBIKE.  These mechanisms include IPv6
    Neighbor Discovery and Address Autoconfiguration [RFC 2461-2462],
    DHCP [RFC 3315], enhanced network detection mechanisms detected by
    the DNA working group, and corresponding IPv4 mechanisms, such as
    [draft-ietf-dhc-dna-ipv4].

2.  Locally Operational Addresses

    Definition.  Locally Operational Address.  An available address is
    said to be locally operational when its use is known to be possible
    locally: the interface is up and the relevant default router (if
    applicable) is known to be reachable.

    Locally operational addresses are discovered and monitored through
    mechanisms outside MOBIKE.  These mechanisms include IPv6 Neighbor
    Discovery [RFC 2461], corresponding IPv4 mechanisms, and link layer
    specific mechanisms.

3.  Operational Address Pairs

    The existence of locally operational addresses are not, however, a
    guarantee that communications can be established with the peer.  A
    failure in the routing infrastructure can prevent the sending of
    packets. For this reason we need the definition of a second level
    of granularity, for pairs addresses:

    Definition.  Bidirectionally operational address pair.  A pair of
    locally operational addresses are said to be an operational address
    pair, iff bidirectional connectivity can be shown between the
    addresses.  That is, a packet sent with one of the addresses in the
    source field and the other in the destination field reaches the
    destination, and vice versa.

    Unfortunately, there are scenarios where bidirectionally operational
    address pairs do not exist.  For instance, ingress filtering or
    network failures may result in one address pair being operational in
    one direction while another one is operational from the other
    direction.  The following definition captures this general situation:

    Definition.  Undirectionally operational address pair.  A pair of
    locally operational addresses are said to be an unidirectionally
    operational address pair, iff packets sent with the first address as
    the source and the second address as the destination can be shown to
    reach the destination.

    Both types of operational pairs are discovered and monitored through
    the following mechanisms:

    o  Positive feedback from upper layer protocols.  For instance, TCP
       can indicate to the IP layer that it is making progress.  This is
       similar to how IPv6 Neighbor Unreachability Detection can in some
       cases be avoided when upper layers provide information about
       bidirectional connectivity [RFC 2461].  In the case of unidirectional
       connectivity, the upper layer protocol responses come back using
       another address pair, but show that the messages sent using the
       first address pair have been received.

    o  Explicit reachability tests.  For instance, the IKEv2 keepalive
       mechanism can be used to test that the current pair of addresses
       is operational.

    o  ICMP error messages.  Given the ease of spoofing ICMP messages,
       one should be careful to not trust these blindly, however.  One
       suggestion is to use ICMP error messages only as a hint to perform
       an explicit reachability test, but not as a reason to disrupt
       ongoing communications without other indications of problems.

4.  Primary Address Pair

    Contrary to SCTP which has a specific congestion avoidance design
    suitable for multi-homing, IP-layer solutions need to avoid sending
    packets concurrently over multiple paths; TCP behaves rather poorly
    in such circumstances.  For this reason it is necessary to choose a
    particular pair of addresses as the primary address pair which is
    used until problems occur, at least for the same session.

    A primary address pair need not be operational at all times.  If
    there is no traffic to send, we may not know if the primary address
    pair is operational.  Neverthless, it makes sense to assume that the
    address pair that worked in some time ago continues to work for new
    communications as well.