Subject: [Mipshop] RE: Stateful configuration and FMIPv6

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Tue, 23 Aug 2005 15:35:51 -0500

I'd vote for either an appendix or a separate document that the spec can point to. 

Regards,
Vidya

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]] 
> Sent: Tuesday, August 23, 2005 11:35 AM
> To: Narayanan Vidya-CVN065; [email-masked]
> Cc: Soliman, Hesham; [email-masked]; Rajeev Koodli; 
> [email-masked]
> Subject: Re: Stateful configuration and FMIPv6
> 
> 
> I think the spec must provide a credible story about how it 
> can be done, or 
> point to another spec that provides such a credible story, in 
> order to have 
> FMIP in shape for proposed standard. Or drop trying to 
> support stateful 
> configuration with predictive handover. In the current 
> situation, I can't 
> see how stateful configuration could be done with predictive 
> handover, 
> except by postulating a mechanism on the NAR that is not 
> defined within this 
> spec or another.
> 
> It's exactly the same problem as with preauthentication for 
> 802.11. The 
> terminal needs to set up some state on the new link before it 
> gets there.
> 
>             jak
> 
> 
> ----- Original Message ----- 
> From: "Narayanan Vidya-CVN065" <[email-masked]>
> To: "'James Kempf'" <[email-masked]>; 
> <[email-masked]>
> Cc: "Soliman, Hesham" <[email-masked]>; 
> <[email-masked]>; "Rajeev 
> Koodli" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, August 23, 2005 9:09 AM
> Subject: Stateful configuration and FMIPv6
> 
> 
> > James, all,
> > Sorry for branching off another thread here, but I had an orthogonal
> > comment on this specific topic and didn't want it to muddle 
> the other 
> > discussion.
> >
> > Why is it necessary for the spec to describe the details on how the 
> > NAR
> > obtains the IP address in the stateful configuration case? 
> This is not 
> > really part of the FMIPv6 protocol in my mind. FMIPv6 must 
> provide the 
> > means of transporting an IP address from the NAR to the MN 
> (which it 
> > already does). But, the specific mechanism by which the NAR 
> obtains this 
> > IP address should perhaps be outside the scope of the spec. 
> If there is a 
> > need for standardizing a mechanism for that (I'm not sure 
> if there is), 
> > perhaps there should be a separate short document that does 
> that (stateful 
> > IP address configuration for FMIPv6).
> >
> > Thoughts?
> >
> > Vidya
> >
> >>
> >> Stateful configuration is the more complex issue, as you have 
> >> mentioned. I can think of a bunch of ways it could be approached:
> >>
> >> 1) Have the NAR maintain a pool of addresses, as you mention. When 
> >> the HI comes in, it picks one out, then sends it back in the HAck.
> >> 2) Have the NAR perform proxy DHCP on behalf of the MN when
> >> the HI arrives, send the HAck back with the address.
> >> 3) Have the MN tunnel DHCP requests to the new link. The MN
> >> could do this proactively every time it discovered a new NAR,
> >> kind of like preauthentication in 802.11r. From an
> >> architctural standpoint, this would probably be the preferred
> >> approach. Or the PAR and NAR could act as a DHCP relay.
> >> 4) Run the DHCP request through a tunnel over HI/HAck.
> >> 5)  Forget about address preconfiguration with stateful. When
> >> the MN moves to the new link, it must perform DHCP. So, in
> >> the stateful case, handovers become reactive.
> >>
> >> None of these is particularly appealing, but I don't think 
> the spec 
> >> deals with stateful configuration very well (if at
> >> all) currently.
> >>
> > 
> 
> 

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Aug 2005 16:33:09 -0700

I think it should probably be a separate spec. I think there might be some 
amount of detail regarding DHCP interaction that would probably be best to 
avoid in the FMIP spec.

        jak

----- Original Message ----- 
From: "Narayanan Vidya-CVN065" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; 
<[email-masked]>
Cc: "Soliman, Hesham" <[email-masked]>; <[email-masked]>; "Rajeev 
Koodli" <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 23, 2005 1:35 PM
Subject: RE: Stateful configuration and FMIPv6

---

From: Greg Daley <[email-masked]>
Date: Thu, 25 Aug 2005 11:59:20 +1000

Hi,

James Kempf wrote:
> I think it should probably be a separate spec. I think there might be 
> some amount of detail regarding DHCP interaction that would probably be 
> best to avoid in the FMIP spec.

Sure.  So long as the base specification doesn't
make assumptions (like the experimental seemed to) that an
allocated address is unique.

There's no existing method which allows unique allocation
of addresses at HAck time (in an RFC2462 compliant manner),
except the advanceDAD method of YounHee Han's (I guess MLD-DAD
does too, but that's dead).  Pre-tested uniqueness tests won't work
with user-selected addresses though.

Transport in this case needs to make the distinction between
leasing/allocation (which may initially occur using DHCPv6 in order
to reduce the critical path configuration time) and uniqueness
testing of addresses.

If there is no uniqueness guarantee possible, the actual testing
of addresses should wait until the host has arrived on-link,
where optimistic DAD can be done.

Greg