[Mip4] AD review of draft-ietf-mip4-fmipv4-06.txt

[Jari Arkko <[e-mail]>]

Pete, all,

I have reviewed this specification and while it is generally
in good shape for an Experimental RFC publication, there
were a number of questions and issues that I believe need
to be addressed before we can go to IETF Last Call.

In Section 3, did you mean "default router reachability"
when you wrote "default agent reachability"?

Section 6.3 says this:

> New Access Point Link-layer Address: The link-layer address or
> identification of the access point for which the MN requests
> routing advertisement information. It MUST be included in all
> RtSolPr messages. More than one such address or identifier can
> be present. This field can also be a wildcard address (see
> Section 7.1).

And then later Section 6.4

> New Access Point Link-layer Address: The link-layer address or
> identification of the access point is copied from RtSolPr
> message. This option MUST be present.
>
> ...
>
> New CoA Option: MAY be present when PrRtAdv is sent
> unsolicited.

There are a couple of issues around the role of New Access Point
Link-layer Address option. Since you allow wildcards, what does
the copying requirement mean? Copy the wildcard, or the matching
entries?

> New CoA Option: MAY be present when PrRtAdv is sent
> unsolicited. PAR MAY compute new CoA using NAR's prefix
> information and the MN's L2 address, or by any other means. In
> any case, the MN should be prepared to use this address instead
> of performing DHCP or similar operations to obtain an IPv4
> address.
First, why would this be present only in an unsolicited message?

Second, the combination of prefix and L2 address appears to be
copied from IPv6 and not directly applicable in IPv4.

Third, how is the lifetime of this address determined? When can the
new access router re-allocate the same address for someone else?
Why is there no instruction on what the NAR/PAR does in order to
find such addresses. RFC 4068 had these instructions... Or are you
saying in Section 1 that you always use foreign agent care-of
address? If so, please require this later in the document when
you transport the addresses around.

In Section 6.4 you say:

> New Access Point Link-layer Address: The link-layer address or
> identification of the access point is copied from RtSolPr
> message. This option MUST be present.
>
> ...
>
> A Proxy Router Advertisement with Code 3 means that new router
> information is only present for a subset of access points requested.
> The Option-Code values in the LLA option distinguish different
> outcomes (see Section 7.1).

If we get Code 3, is there a New Access Point Link-layer Address
option included anyway? What would its contents be, in this case?

> Type: To be assigned by IANA
>
> Code: 0
RtSolPr and PrRtAdv ask for an ICMP Type code
to be assigned. I'm trying to understand why,
given that RFC 4068 uses type code 150 allocated
in RFC 4065 for experimental mobility purposes.
RFC 4065 has a corresponding type code for IPv4,
too (value 41).

> 9. IANA Considerations
>
> All the messages and the option formats specified in this document
> require Type assignment from IANA. Specifically, the Types, Sub-
> types and the Codes need assignment from ICMP, Mobile IP and
> Experimental Mobility Type [rfc4065] registries.

It took a while for me to parse what this means, and it would be
better if you can write the IANA instructions in a more explicit
manner. In particular, you are asking ICMP Types and Mobile IP
Type allocations, so at least explain what values are allocating
from what registry. Also, this section may be affected by
any changes resulting from my previous comment.

Finally, the IANA considerations section is missing all instructions
regarding future allocations from Option-Code and Code fields.
Are these namespaces expected to be independent new spaces,
or go in sync with RFC 4068?

Jari



-- 
Mip4 mailing list: [e-mail]
    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/