Subject: [nemo] Implemetor's comments on RFC3963

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Oct 2005 16:20:05 +0200

Dear all,

Here are some remarks that came up while implementing RFC3963 MR and HA
on laptops over iWiFi.

page 12, last par:
>    If the Binding Acknowledgement from the Home Agent has the status
>    140, the Mobile Router SHOULD send a Binding Update to another Home
>    Agent on the same home link.

But how could the MR know another HA?  The only way to build the HA list
is currently with DHAAD.  Per rfc3775 DHAAD is not mandatory to happen,
and the bootstrapping procedure is not yet fixed.

In addition, even if the MR learns a list of HAs by some other means
(like manual configuration), the MR should probably not send a BU to
another HA which only supports MHs.

So I suggest to relax the SHOULD from above to a MAY, and probably later
make it a MUST.  Additionally, I suggest to send the BU to another HA
that supports Mobile Routers (not just any HA).

page 14, 1st par:
> However, the Mobile
>    Router SHOULD reply with Neighbor Advertisements to Neighbor
>    Solicitations received on the egress interface, for addresses valid
>    on the visited link.

It was not immediately obvious what a "valid address on the visited
link" is, terminology of "valid address on a link" is not yet widely
used by the non-IETF.  So it would be good to shortly explain the "valid
address".

For example, "for addresses derived from that link's prefix, that do not
risk being ingress filtered by that link's router" or similar.

page 15, last bullet, and over to page 16:
>    -  If a Mobile Network Prefix Option is present in the Binding
>       Update, the prefix information for the Mobile Network Prefix is
>       retrieved from the Mobile Network Prefix field and the Prefix
>       Length field of the option.  If the Binding Update contains more
>       than one option, the Home Agent MUST set up forwarding for all the
>       Mobile Network Prefixes.  If the Home Agent fails to set up
>       forwarding to all the prefixes listed in the Binding Update, then 
>       it MUST NOT forward traffic to any of the prefixes.  Furthermore,
>       it MUST reject the Binding Update and send a Binding
>       Acknowledgement with status set to 141 (Invalid Prefix).
> 
>       If the Home Agent verifies the prefix information with the Prefix
>       Table and the check fails, the Home Agent MUST discard the Binding
>       Update and send a Binding Acknowledgement with status set to 142
>       (Not Authorized for Prefix).

Security-wise, the implementation order of verification would put the
last par before the middle of the first par:  the HA first checks the
MNP against the Prefix Table and only then it tries to set up forwarding.

So I suggest re-writing these two paragraphs as:

       "If a Mobile Network Prefix Option is present in the Binding
        Update, the prefix information for the Mobile Network Prefix is
        retrieved from the Mobile Network Prefix field and the Prefix
        Length field of the option.

        If the Home Agent verifies the prefix information with the
        Prefix Table and the check fails, the Home Agent MUST discard
        the Binding Update and send a Binding Acknowledgement with
        status set to 142 (Not Authorized for Prefix).  This
        verification should happen for all Mobile Network Prefixes
        present in that Binding Update and if any one fails then send
        status 142 (Not Authorized for Prefix).

        If all Mobile Network Prefixes verifications against the Prefix
        Table are successfull, the Home Agent MUST set up forwarding for
        all the Mobile Network Prefixes.  If the Home Agent fails to set
        up for at least one prefixe listed in the Binding Update, then
        it MUST NOT forward traffic to any of the prefixes.
        Furthermore, it MUST reject the Binding Update and send a
        Binding Acknowledgement with status set to 141 (Invalid
        Prefix)."

The detail explanation of how the search in the Prefix Table could help
too, especially since we count on the Prefix Table as a security measure.

-would HA check the HoA for every entry's HoA field and then match the
 MNP in the BU against that entry's MNP field?
-or would it first check the MNP and then the HoA?
-what's a successfull check.

page 16, 2nd bullet:
>   -  If there is no option in the Binding Update carrying prefix
>       information, the Home Agent uses manual pre-configured information
>       to determine the prefixes assigned to the Mobile Router and to set
>       up forwarding for the Mobile Network.  If there is no information
>       that the Home Agent can use, it MUST reject the Binding Update and
>       send a Binding Acknowledgement with status set to 143 (Forwarding
>       Setup failed).

It was not immediately obvious what "manual pre-configured information"
represents.  Maybe it would be clearer to just say "routing table"
instead of explaining "manual pre-configured information".

If we are specific about that being a "routing table" then further
explanation in the same paragraph is also easier.  Because, there was
another thing not immediately clear: how would the HA "use" that "manual
pre-configured information"?  What would HA use as a key to search that
information?  Fixed-match or longest-prefix match?  What would be a
successful search?

If we say it's a "routing table" then we can also simply say that the HA
"checks the HoA from the BU against every GW field of the routing table,
and when a match is found the corresponding prefix field of the table is
used as a substitute for the MNP that would have come from the BU", or
similar.

Otherwise it's not clear at all how that "use of manual pre-configured
information" should be implemented.

page 20, last par:
>   A new flag (R) (Support for Mobile Routers) is introduced in the
>    DHAAD Reply message, defined in [1].  If a Home Agent receives a
>    Dynamic Home Agent Discovery request message with the Mobile Router
>    Support Flag set, it MUST reply with a list of Home Agents supporting
>    Mobile Routers.  The Mobile Router Support Flag MUST be set if there
>    is at least one Home Agent supporting Mobile Routers.  If none of the
>    Home Agents support Mobile Routers, the Home Agent MAY reply with a
>    list of Home Agents that only support Mobile IPv6 Mobile Nodes.  In
>    this case, the Mobile Router Support Flag MUST be set to 0.

Again on terminology of "Mobile Nodes".  What we want to achieve with
the above par is that if there's no HA supporting MRs then the HA should
reply with a list of HAs that only support Mobile Hosts.  So I suggest
substitute Mobile Hosts for Mobile Nodes in the paragraph above.

(at several places throughout 3963 we made good distinction Mobile Host
- Mobile Router and avoided "Mobile Node").

page 21, the message format:
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |     Code      |            Checksum           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |           Identifier          |R|           Reserved          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    +                                                               +
>    +                                                               +
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It would be convenient if that wide field after "Reserved" would have a
textual description pasted on it, about its contents.  Otherwise and
implementor has to dig it in rfc3775.

That's all we have up to now, and all other preceding text was easily
understood and we have it implemented and tested, we're happy with that.

Alex