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

[Rajeev Koodli <[e-mail]>]

Hi Jari,

Thanks for the review. See my responses inline.


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

Yes (we have assumed FA acting as a router).
> 
> 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?
> 

It's the LLA. Wildcard only says provide information about all possible
neighborhood access points.

PrRtAdv contains the [AP-ID, AR-Info] tuple, which is what you see as Valid
options in Section 6.4. Multiple such tuples may be present as a result of
multiples LLAs present or a wildcard request in RtSolPr.

So, the copy statement is applicable to LLAs present in RtSolPr. When the
wildcard is present, PAR includes the LLA on its own. If it would help, I
can add a sentence to make it clear.


>> 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?

In RFC 4068, the unsolicited mode means a network-initiated handover, in
which case the MN needs an NCoA, which is supplied in PrRtAdv. We have
re-used it here, even though we do not bind the PCoA to NCoA (but to the new
FA's address). 
 
> 
> Second, the combination of prefix and L2 address appears to be
> copied from IPv6 and not directly applicable in IPv4.

Yes.

> 
> 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.
> 

Even with New CoA, the binding is always for the new FA's address. I will
add this requirement again in Section 6.4.


> 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?
> 

Yes. It is only saying that the [AP-ID, AR-Info] tuples are present for only
a subset of all the APs included in the RtSolPr.


>> 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).
> 

You are right. I forgot to update it after writing the IANA section.

>> 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.

The subsequent paragraphs describe what assignments are needed, no?


> 
> 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?
> 

I assumed they would just be in sync with RFC 4068. I can add some text as
such.

-Rajeev


> 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/