Subject: [mobile-ip] FMIPv6 questions

From: Teemu Rinta-aho <[email-masked]>
Date: Mon, 11 Nov 2002 10:33:38 +0200 (EET)

Hi all,

we're currently implementing FMIPv6 and after reading the draft
there are two issues that need clarification:

- Both FBACK and NAACK give the status of the NCoA. Which one to obey,
  if the result codes differ? I know they shouldn't, but if they do?

- In which cases should the PAR suggest a NCoA to NAR? Why can't it just
  request a NCoA every time, and the NAR could allocate the address any
  way it wants (stateless or stateful)? This would make the signalling and
  implementation less complicated. How can the PAR know whether the new
  access network is using stateful or stateless address autoconfiguration
  if it has never contacted the NAR before?

BR,
Teemu

--
Teemu Rinta-aho                    Tel: +358 9 299 3078
NomadicLab, Ericsson Research      Fax: +358 9 299 3535
Oy L M Ericsson Ab                 Mobile: +358 40 562 3066
FIN-02420 Jorvas, Finland          E-mail: [email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 11 Nov 2002 09:59:18 -0800

>   if the result codes differ? I know they shouldn't, but if they do?

if they differ, go with NAACK. though I dont know why PAR would say
the newCoA is invalid when the new AR says the newCoA is valid. have
you come across a scenario where they would differ? (they shold never
IMO)

> 
> - In which cases should the PAR suggest a NCoA to NAR? 

if NAR is using stateless address configuration.

> Why can't it just
>   implementation less complicated. 

true, the implementation becomes simpler. but if stateless is being 
used, HI/HACK can be done at the same time as ProxyRtrAdvert/FBU. 
this speeds up things. the PAR cannot respond with a FBack till it
receives HACK.

> How can the PAR know whether the new

it knows it the same way as it knows the prefix and MAC address of NAR.
either through manual configuration or through a protocol like CARD
(Seamoby WG).

hope that answers your questions.

regards
Vijay

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Nov 2002 12:54:05 -0800

> you come across a scenario where they would differ? (they shold never

I think it would be a lot simpler if we established an invariant: that the MN
knows after reception of the PrxyRtSol whether or not it has a confirmed address
on the new link. This would:

    - allow the F-NA to be dropped. It serves no other purpose than to provide
the MN with a way to confirm the new CoA when the MN is "unsure" of whether the
new CoA is valid. Why should the MN ever be "unsure"?

    - make the error case simple. If the MN doesn't have a confirmed address, it
simply roles over to performing standard MIPv6.

> this speeds up things. the PAR cannot respond with a FBack till it

Why not let the MN propose a new host identifier suffix to new AR via the
PrxyRtSol to old AR and HI/HAck from old AR to new AR (or old AR can propose it
if the handover is network triggered), and have new AR either return a valid
address or return an error saying it can't return one? This would unify the
stateless and stateful cases, since the returned address could be a statefully
allocated one, and old AR wouldn't have to know how new AR does address
allocation.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 11 Nov 2002 14:04:22 -0800

Hello Teemu,

> we're currently implementing FMIPv6 and after reading the draft

Good.

>   if the result codes differ? I know they shouldn't, but if they do?

NAACK should reflect the most recent state at the new AR, and you
should use it.

>   implementation less complicated. How can the PAR know whether the new

It could. However, as was pointed out, the MN would have to wait longer
to receive PrRtAdv (previous AR has to wait until it receives a HAck).

>   if it has never contacted the NAR before?

Much the same way it collects other information.

Thank you for your questions.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 11 Nov 2002 14:04:22 -0800

Hello Teemu,

Good.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Nov 2002 12:54:05 -0800

jak