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

From: Eva Fogelström <[email-masked]>
Date: Tue, 01 Aug 2006 13:38:33 +0200

Hi Jari,

Comments inline.

Jari Arkko wrote:

>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.
>  
>
Yes. I believe the original intention was to support FAs with private 
addresses in regional registrations. However, unless someone has a real 
need for this feature, we can skip it and instead make it so that 
regular MIP4 clients can always get service, according to your 
suggestion. Comments?

>  
>
>>   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?
>  
>
The draft specifies regional registrations in visited domains, but we 
could update it to support regional registrations in the home domain as 
well. I see no particular reason to prevent it.

>  
>
>>                      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.
>  
>
Yes. I'll clarify.

>  
>
>>   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?
>  
>
This draft only specifies the first and the last. Anything in between is 
out of scope. I'll clarify.

The editorial comments I'll take care of when updating the draft.

Eva

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

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 1 Aug 2006 07:17:18 -0700

________________________________________
From: Eva Fogelström [mailto:[email-masked]] 
Sent: Tuesday, August 01, 2006 7:39 AM
To: Jari Arkko
Cc: [email-masked]
Subject: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt

Hi Jari,

Comments inline.

Jari Arkko wrote: 
Eva and others,

  
Yes. I believe the original intention was to support FAs with private addresses in regional registrations. However, unless someone has a real need for this feature, we can skip it and instead make it so that regular MIP4 clients can always get service, according to your suggestion. Comments? 

GT> Is this really about private addresses? Or is it about dynamic GFA assignment? I think dynamic GFA assignment is purely defined in this document so cleaning it out might be a good idea. We can define dynamic GFAs in a separate draft if there is still interest.

George