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

[Jari Arkko <[e-mail]>]

Rajeev,

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

Please change the text -- if you actually provide the link
layer addresses for all access points, then you are not
copying the LLA option from request to advertisement;
you are replacing the wildcard LLA with a number of
specific LLAs, right?

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

Ok, but are you saying that if the mobile node initiates
the handover, then the PAR can not provide an NCoA?
That is, what is the keyword  that you would use for
solicited messages? MAY as well? Or maybe MUST NOT,
if you disallow this?

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

Good.

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

That's fine, but then it also means that the MUST that appeared
earlier about the copying of LLAs from request to advertisement
cannot be fulfilled. You need to adjust the MUST statement
to say what you actually need to be done. Currently it makes
an overall statement that does not appear to be the desired
behaviour in a number of special cases (wildcard, code 3).

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

Ok, please update this.

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

Ah, yes. I must have been looking at the old revision.

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

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/