Subject: RE: [Mip4] HA=0.0.0.0 question (HA Discovery)

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 19 Jul 2005 22:39:39 -0400

This sounds ok to me.
Thanks
George

> -----Original Message-----
> From: Kent Leung (kleung) [mailto:[email-masked]] 
> Sent: Tuesday, July 19, 2005 1:52 PM
> To: Tsirtsis, George; Pete McCann; Ranjitsinh Wable
> Cc: [email-masked]
> Subject: RE: [Mip4] HA=0.0.0.0 question (HA Discovery)
> 
> 
> Hi George.
> 
> In RFC 3344, section 3.6.1.2:
> 
>    The Home Agent field MUST be set to the address of the 
> mobile node's
>    home agent, if the mobile node knows this address.  Otherwise, the
>    mobile node MAY use dynamic home agent address resolution to learn
>    the address of its home agent.  In this case, the mobile node MUST
>    set the Home Agent field to the subnet-directed broadcast 
> address of
>    the mobile node's home network...
> 
> There is no explicit specification on how FA should deal with 
> HA field that is 0.0.0.0.  So let's find out what can be implemented?
> 
> 1) FA forward the RRQ as specified in RFC 3344.  This means 
> that the dest IP addr of the RRQ will be set to the HA field. 
>  Scenario covered in draft as "Legacy foreign agents may forward ...".
> 
> 2) FA sends reject RRP to MN, as mentioned by you.
> 
> I don't think there are any other possibilities.  If so, 
> here's the new amended text:
> 
> draft-ietf-mip4-dynamic-assignment-04.txt, section 10:
> 
> 2. If the MN does not receive a Registration Reply within some time 
>      and/or after sending a few Registration Requests, it can assume 
>      that the Registration Request(s) has been dropped, either by a 
>      legacy FA or an incorrect HA.  In addition, if the 
> registration is 
>      denied with error code 70 (poorly formed Request), the 
> MN can assume
>      that the legacy FA cannot process this message.  In either case,
>      the MN should fall back to a 
>      recovery mechanism.  The MN should quickly send a new 
> Registration 
>      Request as mentioned in section 4.1 step 2.  This step 
> will ensure 
>      that a legacy FA will forward the Registration Request 
> to the Home 
>      Agent thereby making dynamic HA assignment possible. 
> 
> Is this OK?
> 
> Kent 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Tsirtsis, George
> > Sent: Monday, July 18, 2005 12:12 PM
> > To: Pete McCann; Ranjitsinh Wable
> > Cc: [email-masked]
> > Subject: RE: [Mip4] HA=0.0.0.0 question (HA Discovery)
> > 
> > Hi everyone....have not been here for a while....
> > 
> > I think the paragraph quoted below should be removed from the
> > draft since it is not possible to suggest what "legacy" 
> > equipment need to do in addition to what the already do. One 
> > can only observe what the reaction of an existing 
> > implementation might be based on the legacy specification.
> > 
> > A legacy FA will probably support just what is in RFC3344,
> > which does not include the idea of HA==0. I would guess that 
> > such an FA might just return a RREP with Code==70 "poorly 
> > formed Request".
> > 
> > Regards
> > George
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > On Behalf
> > > Of Pete McCann
> > > Sent: Monday, July 18, 2005 10:37 AM
> > > To: Ranjitsinh Wable
> > > Cc: [email-masked]
> > > Subject: [Mip4] HA=0.0.0.0 question (HA Discovery)
> > > 
> > > 
> > > 
> > > Hi,
> > > 
> > > The use of ALL-ZERO-ONE-ADDR for the HA address is specified in
> > > draft-ietf-mip4-dynamic-assignment-04.txt.  This may be a good 
> > > opportunity to remind the group that we should still be 
> > discussing the
> > > resolution of Thomas Narten's comment on this draft, namely:
> > > 
> > > > >    Legacy Foreign Agent:
> > > > >   
> > > > >    Legacy foreign agents may forward a Registration
> > > Request with home
> > > > >    agent field set to ALL-ZERO-ONE-ADDR by setting the
> > > destination IP
> > > > >    address to ALL-ZERO-ONE-ADDR.  This will result packet
> > > being dropped
> > > > >    or incidentally handled by a next hop HA, adjacent to
> > > the FA.   
> > > > 
> > > > hmm. how does one distinguish network connectivity problems
> > > from "not
> > > > implemented"? I.e, what recovery action does a MN take in this
> > > > situation?
> > > 
> > > We have had some discussion on this but I am not sure we reached a
> > > final conclusion.
> > > 
> > > -Pete
> > > 
> > > 
> > > Ranjitsinh Wable writes:
> > >  > Hi all,
> > >  >
> > >  > Here I am having small question regarding the MIPv4.
> > >  > Few days back on the mailing list I saw the discussion
> > > about the 
> > > HoA being 0.0.0.0 but what if the HA address  > itself is 
> zero. RFC 
> > > 3344 does not talk about this case.
> > >  > It talks about the dynamic HA discovery using the  > subnet 
> > > broacast messages.
> > >  >
> > >  > What if the HA address in the RRQ is 0.0.0.0.
> > >  > Is it the same procedure to resolve the HA address  > 
> > using NAI of
> > > the MN and AAA server?
> > >  >
> > >  > Is there any standard stating the use of NAI of MN  > 
> to resolve
> > > the HA of MN.
> > >  >
> > >  > Thanks in advance.
> > >  >
> > >  > Regards,
> > >  >
> > >  > Wable R. U.
> > > 
> > > 
> > > --
> > > 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/
> > > 
> > 
> > ===========================================================
> > This email may contain confidential and privileged material
> > for the sole use
> >  of the intended recipient.  Any review or distribution by 
> > others is strictly
> >  prohibited.  If you are not the intended recipient please 
> > contact the sender
> >  and delete all copies.
> > ===========================================================
> > 
> > 
> > --
> > 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/
> > 
> 

-- 
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: Pete McCann <[email-masked]>
Date: Wed, 20 Jul 2005 13:32:54 -0500

Ok, I think we can take this as the resolution.

Kent, please prepare a new version and be ready to upload it when
submissions re-open.

-Pete