Subject: [mobile-ip] Issue #179 proposed resolutions

From: Charlie Perkins <[email-masked]>
Date: Mon, 02 Dec 2002 16:48:57 -0800

This issue is actually a number of smaller issues related to
sending and receiving Router Advertisements from the
home agent.  Some proposals inline.

Regards,
Charlie P.

Thomas Narten writes:

>     -  However, if the Single Address Only (S) bit field in the
Binding
>        Update is zero, the lifetime for that Binding Cache entry MUST
>        NOT be greater than the minimum remaining valid lifetime for
all
>        subnet prefixes on the mobile node's home link.  If the value
of
>        the Lifetime field specified by the mobile node in its Binding
>        Update is greater than this prefix lifetime, the home agent
MUST
>        decrease the binding lifetime to less than or equal to the
prefix
>        valid lifetime.

Seems like this might play havoc with renumbering, where the lifetime
of a specific prefix is intended to go to 0.

================ CEP Comment
============================================
        Good point.  It needs to be reworded so that lifetimes of
        less than or equal to two hours are disregarded in the
        determination of the value to be used for the binding lifetime.
=========================================================================

>    A mobile node on a remote network SHOULD autoconfigure all of the
>    global IP addresses, which it would autoconfigure if it were
attached
>    to its home network and which are from prefixes served by home
>    agents.  Site-local addresses MAY be autoconfigured if the mobile
>    node is roaming in a network on the same site as its home
addresses.
>    Site-local addresses and addresses not served by a home agent MUST
>    NOT be autoconfigured, since they are unusable in the remote
network.

Addresses not served by the HA should not be autoconfigured? Huh? why
is the MN learning of addresses not supported by the HA?

============= CEP Comment
================================================
        Proposal: delete "and addresses not served by a home agent"
=========================================================================

>     -  Copy prefix information defined in the home agent's
AdvPrefixList
>        on the home subnet's interfaces to the aggregate list.  Also
>        apply any changes made to the AdvPrefixList on the home agent
to
>        the aggregate list.
>
>     -  Check valid prefixes received in Router Advertisements from the

>        home network for consistency with the home agent's
AdvPrefixList,
>        as specified in Section 6.2.7 of RFC 2461 [12].  Do not update
>        the aggregate list with any information from received prefixes
>        that fail this check.

Is this enough? It may be that some routers only advertise some of the
info. Does that info also need to get proxied to the MN? (Note: maybe
the ND spec should say different nodes can advertise different things,
but all nodes should be configured to advertise the same info over
time, in case one of the other rouers goes down. I.e., you could have
alternating advertisements with every second message advertising
information X, the other Y. Then you could proxy based entirely on
configured information. This probably ought to be discussed in the
IPv6 WG ...)

=========== CEP Comment
==================================================
        Proposal: This is the best we can do for now...?
=========================================================================

>     -  Do not perform consistency checks on valid prefixes received
>        in Router Advertisements on the home network that do not exist
>        in the home agent's AdvPrefixList.  Instead, if the prefixes
>        already exist in the aggregate list, update the prefix lifetime

>        fields in the aggregate list according to the rules specified
for
>        hosts in Section 6.3.4 of RFC 2461 [12] and Section 5.5.3 of
RFC
>        2462 [13].

seems like info from the routers own AdvPrefixList should not be
overridden by RAs from other routers. If nothing else, there will be
inconsistencies related to lifetimes and clock syncronization issues.

=========== CEP Comment
==================================================
        Proposal: add "unless the update would override existing
                       information from the home agent"
=========================================================================

>     -  If the L flag is set on valid prefixes received in a Router
>        Advertisement, and that prefix already exists in the aggregate
>        list, set the flag in the aggregate list.  Ignore the flag if
it
>        is clear.

Override info from the routers own config files? Doesn't seem wise.

=========== CEP Comment
==================================================
        Proposal: Similarly, add "unless the setting of the 'L bit was
already
                       preconfigured at the home agent"
=========================================================================

>    MAY:
>
>     -  A new prefix is added to the aggregate list.

why not SHOULD or MUST?

============ CEP Comment
=================================================
        The reasoning was that this is not such an urgent event
        to cause immediate signaling at perhaps many thousands of
        mobile nodes.  Instead, the signaling could presumably be
        delayed according to the time distribution given by the
        arrival of Binding Updates from each mobile node.

        However, if this reasoning underestimates the typical
        urgency of the operation, the spec can be upgraded in force.
=========================================================================

>     -  The Home Agent Addresses field SHOULD contain one global IP
>        address for each home agent currently listed in this home
agent's
>        own Home Agents List (Section 10.1).  However, if this home
>        agent's own global IP address would be placed as the first
entry
>        in the list (as described below), then this home agent SHOULD
NOT
>        include its own address in the Home Agent Addresses field in
the
>        Reply message.  Not placing this home agent's own IP address in

>        the list will cause the receiving mobile node to consider this
>        home agent as the most preferred home agent; otherwise, this
home
>        agent will be considered to be preferred in its order given by
>        its place in the list returned.

yet another questionable micro-optimization...

=========================================================================

        This often allows the Home Agent Addresses to be empty, which
        is good percentage-wise.  I think the motivation was to reduce
        by a little bit the number of times that the list would be too
large to
        fit in a single packet.   With wireless, it's allowable to be
frugal.
        For this reason, I'd be willing to keep the feature.  If it's
important
        to be deleted, it can be deleted.  No one seems to have voiced
any
        opinion about it on the mailing list, though.
=========================================================================

>     -  If the Reply message packet must be truncated to fit within the

>        minimum IPv6 MTU, and the home agent sending the message is
>        not the highest priority, then its address MUST appear in the
>        list sent to avoid implying that it is the highest priority.
>        Therefore, if this home agent would not appear in the truncated

>        list because it is of lower priority than the last entry, this
>        home agent's address must be substituted for the last entry.

a kludge because of the earlier micro-optimzation...

=========================================================================

        This is to cover a situation which would not happen often.
        Plus, some people didn't seem to think it was a kludge.
=========================================================================