Subject: [Mip4] AD review of draft-ietf-mip4-reg-tunnel-02.txt

From: Jari Arkko <[email-masked]>
Date: Wed, 26 Jul 2006 18:44:51 +0300

Eva and others,

I have performed my AD review on this draft. Overall, its
ready for publication as Experimental. However, there are
two technical issues and a few other nits that I would like
to discuss before submission to the IESG.

>    A domain that supports regional registrations SHOULD also be
>    backwards compatible.
>
>    If a FA only advertises an all-ones care-of address (i.e. for dynamic
>    GFA assignment), it will not be backwards compatible with [RFC3344],
>    since the MNs and HAs will also be required to support the regional
>    registration extensions defined in this document.

This seems to suggest a model where those who employ this
mechanism may end up preventing regular Mobile IP clients
from getting service. I do not see why we would have to make this
so. I wonder if it would be better to require both a regular address
and gateway address (possibly all-ones) to be advertised? You could
still require that mobile nodes compliant to reg-tunnel use
dynamic assignment.

>    When a MN moves to a new domain (determined by comparing its NAI with
>    the FA-NAI included in received Agent Advertisements), it can opt to
>    use Regional Registrations. 

>    If the MN receives an Agent Advertisement with the care-of address
>    field indicating the GFA set to all-ones, and if the MN determines
>    that it is within the same visited domain as when it did its last
>    home registration, it MAY send a Regional Registration Request to its
>    current GFA.  Otherwise, it MUST send a Registration Request to its
>    HA as described in Section 7.1.

>    Upon receipt of an Agent Advertisement message with the 'I' flag set
>    and a FA-NAI extension, the MN compares the domain part of the FA NAI
>    with the domain part of its own NAI, to determine whether it is in
>    its home domain or in a visited domain.  If the NAIs do not match,
>    the MN MUST assume it is in a foreign domain.  Otherwise, if the MN
>    determines that it is in its home domain, it acts as defined in
>    [RFC3344].

This process produces two bits as output:

1) Did we move?
2) Are we in the home domain?

I see a lot of value in determining 1. But is there a value in determining
2? Does this imply that you can not use regional registrations within
the home domain? Do we want or need to prevent that?

>                       Registration denied by the GFA:
>
>            +---------------------+-------+---------------------+
>            | Error Name          | Value | Section of Document |
>            +---------------------+-------+---------------------+
>            | REPLAY_PROT_UNAVAIL | TBD   | Section 5.3         |
>            | ZERO_COA_NOT_SUPP   | TBD   | Section 7.3         |
>            +---------------------+-------+---------------------+
>
>         Registration denied by the HA (for dynamic GFA assignment):
>
>            +---------------------+-------+---------------------+
>            | Error Name          | Value | Section of Document |
>            +---------------------+-------+---------------------+
>            | ZERO_CAREOF_ADDRESS | TBD   | Section 7.4         |
>            | ZERO_COA_NOT_SUPP   | TBD   | Section 7.4         |
>            +---------------------+-------+---------------------+

ZERO_COA_NOT_SUPP appears twice, but presumably this
is the same value? If yes, please clarify so that neither IANA
or readers will get confused.

>    If the
>    'I' flag is set, and there are multiple care-of addresses, the first
>    care-of address is the local FA, and the last care-of address is the
>    GFA.

Hmm... this seems to specify only the role of the first and the last
address. What about the rest?

Nits:

>  - The document seems to lack the recommended RFC 2119 boilerplate, even if
>    it appears to use RFC 2119 keywords -- however, there's a paragraph with a
>    matching beginning. Boilerplate error?
>  
>
Warning from idnits.

>  - Unused Reference: 'RFC2486' is defined on line 1345, but not referenced
>
Another idnits warning.

Also, if you want to refer to RFC 2486, it has been obsoleted by RFC 4282.
So use 4282 if you need it.

The document talks about NAIs, so I would assume that a reference is
needed.

>    to be protected by a MN-FA Authenticaion extension.

Typo.

--Jari

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/