Subject: [mobile-ip] Mipv6 issue #100 (samita's comments on draft 18)

From: Jari Arkko <[email-masked]>
Date: Thu, 24 Oct 2002 15:15:52 +0300

Hi,

I have reviewed this issue and I think we have missed a few things, and
also didn't send the full text fix.

The main thing that we missed was that the spec requires us to silently
discard BUs with any other basic validation problem than old nonce or
sequence number. Hence, it doesn't appear to be possible to send a 137
at all unless we change the other rule. (It looks to me like dropping
the packet is the right thing to do in any case.)

See below for text:

1. Section 4.1 new text:

    A mobile node is always expected to be addressable at its home
    address, whether it is currently attached to its home link or is
    away from home.  The "home address" is an IP address assigned to the
    mobile node within its home subnet prefix on its home link.  While
    a mobile node is at home, packets addressed to its home address are
    routed to the mobile node's home link, using conventional Internet
    routing mechanisms.

    While a mobile node is attached to some foreign link away from home,
    it is also addressable at one or more care-of addresses.  A care-of
    address is an IP address associated with a mobile node that has the
    subnet prefix of a particular foreign link.  The mobile node can
    acquire its care-of address through conventional IPv6 stateless or
    stateful auto-configuration mechanisms.  As long as the mobile node
    stays in this location, packets addressed to this care-of address
    will be routed to the mobile node.  The mobile node may also accept
    packets from several care-of addresses, such as when it is moving but
    still reachable at the previous link.

    The association between a mobile node's home address and care-of
    address is known as a "binding" for the mobile node.  While away
    from home, a mobile node registers its primary care-of address with
    a router on its home link, requesting this router to function as the
    "home agent" for the mobile node.  The mobile node performs this
    binding registration by sending a "Binding Update" message to the
    home agent.  The home agent replies to the mobile node by returning a
    "Binding Acknowledgement" message.  The operation of the mobile node
    and the home agent is specified in Sections 11 and 10, respectively.

    Any node communicating with a mobile node is referred to in this
    document as a "correspondent node" of the mobile node, and may itself
    be either a stationary node or a mobile node.  Mobile nodes can
    provide information about their current location to correspondent
    nodes.  This happens through the correspondent binding procedure.  As
    a part of this procedure, a return routability test is performed in
    order to authorize the establishment of the binding.  The operation
    of the correspondent node is specified in Section 9.

    There are two possible modes for communications between the mobile
    node and a correspondent node.  The first mode, bidirectional
    tunneling, does not require Mobile IPv6 support from the
    correspondent node and is available even if the mobile node has not
    registered its current binding with the correspondent node.  Packets
    from the correspondent node are routed to the home agent and then
    tunneled to the mobile node.  Packets to the correspondent node are
    tunneled from the mobile node to the home agent ("reverse tunneled")
    and then routed normally from the home network to the correspondent
    node.  In this mode, the home agent uses proxy Neighbor Discovery
    to intercept any IPv6 packets addressed to the mobile node's home
    address (or home addresses) on the home link.  Each intercepted
    packet is tunneled to the mobile node's primary care-of address.
    This tunneling is performed using IPv6 encapsulation [15].

    The second mode, "route optimization", requires the mobile node to
    register its current binding at the correspondent node.  Packets
    from the correspondent node can be routed directly to the care-of
    address of the mobile node.  When sending a packet to any IPv6
    destination, the correspondent node checks its cached bindings for
    an entry for the packet's destination address.  If a cached binding
    for this destination address is found, the node uses a new type of
    IPv6 Routing header [11] (see section 6.4) to route the packet to the
    mobile node by way of the care-of address indicated in this binding.

    Routing packets directly to the mobile node's care-of address also
    eliminates congestion at the mobile node's home agent and home link.
    In addition, the impact of any possible failure of the home agent or
    networks on the path to or from it is reduced.

    When routing packets directly to the mobile node, the correspondent
    node sets the Destination Address in the IPv6 header to the care-of
    address of the mobile node.  A new type of IPv6 Routing Header (see
    Section 6.4) is also added to the packet to carry the desired home
    address.  Similarly, the mobile node sets the Source Address in
    the packet's IPv6 header to its current care-of addresses.  The
    mobile node adds a new IPv6 "Home Address" destination option (see
    Section ??)  to carry its home address.  The inclusion of home
    addresses in these packets makes the use of the care-of address
    transparent above the network layer (e.g., at the transport layer).

    Mobile IPv6 also provides support for multiple home agents, and the
    reconfiguration of the home network.  In these cases, the mobile
    node may not know the IP address of its own home agent, and even
    the home subnet prefixes may change over time.  A mechanism, known
    as "dynamic home agent address discovery" allows a mobile node to
    dynamically discover the IP address of a home agent on its home
    link, even when the mobile node is away from home.  Mobile nodes can
    also learn new information about home subnet prefixes through the
    "prefix discovery" mechanism.  These mechanisms are described in
    Sections 10.10 and 11.4.1.

2. Lifetime value 0xffffffff has been changed to 0xffff.

3. Error code 137. The current text in 9.4.1. requires
    us to silently discard BUs that have other basic
    validation problems than old nonce indexes or
    sequence numbers. This seems right, and hence
    137 can not be sent in any case. This code
    will be removed.

4. The status code 1 (Home Address destination option used without
    a binding) has been renamed to "Unknown binding for Home Address
    destination option", and given our earlier agreement on not
    using solely IPsec-protected HAOs this seems now correct.

5. As Charlie noted, we already had text for sending the BE
    upon illegal HAO. Anyway, Section 9.2.2 contents are now:

    Packets containing a Home Address option MUST be dropped if the
    given home address is not a unicast routable address.

    Packets containing a Home Address option MUST also be dropped if
    there is no corresponding Binding Cache entry for the given home
    address.  A corresponding Binding Cache entry MUST have the currently
    registered care-of address equal to the source address of the packet.
    A packet that contains a Binding Update message and a Home Address
    option is considered to pass the above tests if the Binding Update
    successfully creates or updates a Binding Cache entry.

    If the packet is dropped due the above tests, the correspondent node
    SHOULD send the Binding Error message as described in Section 9.4.6.
    The Status field in this message should be set to 1 (unknown binding
    for Home Address destination option).

6. Section 9.4.6 contents:

    Sections 9.2.1 and 9.2.2 describe error conditions that lead to a
    need to send a Binding Error message.

    A Binding Error message is sent to the address that appeared in the
    IPv6 Source address field of the offending packet.

    The Home Address field in the Binding Error message MUST be copied
    from the Home Address field in the Home Address destination option of
    the offending packet, or set to the unspecified address if no such
    option appeared in the packet.

    Binding Error messages are subject to rate limiting in the same
    manner as is done for ICMPv6 messages [ref].

7. Section 10.3 text

    -  The Refresh field MUST be set to zero.

    has been changed to

     -  The Binding Refresh Advice mobility option MUST be omitted.

8. We have added a term for registration

       registration
                 The process during which a mobile node sends a
                 Binding Update to its home agent, causing the home agent
                 to take the actions which will enable packets to be
                 forwarded from the mobile node's home network to the
                 mobile node's care-of address.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 24 Oct 2002 12:06:02 -0700

Hello Jari,

I generally like the idea of home agents silently dropping
BUs that have bad authenticators.  If a mobile node can't
form a correct authenticator, getting an error message with
that information from the home agent isn't going to help.

For correspondent nodes, we have to be sure that nonce indices
are not re-used soon enough that an index could be valid
at the same time that a mobile node is using it to point to
an invalid nonce.  I don't think that is a problem, but if
there is no error 137 we have to be sure about it.

For debugging, error 137 is quite handy.  I would like to
see the specification allow for such a mechanism between
the nodes for testing purposes, even if it's not enabled
for production systems or commercial deployments.

Regards,
Charlie P.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 24 Oct 2002 23:46:35 +0300

> for production systems or commercial deployments.

Charlie, I agree with the issue about the nonce indices. But
the proposal was not to remove error codes 138-140 which
would be used to report about such problems. What is currently
known as 137 (bad authenticator) means that we've sent a BU
to a CN without BAD or that the BAD contains an invalid MAC.
Given that timing problems will result in 138-140, I don't
see any other way to end up with a missing or wrong MAC
than an implementation error. Does the existence of 138-140
and this explanation ease your concern about removing 137?

Jari