Subject: RE: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FN A)

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Fri, 12 Aug 2005 06:48:37 -0500

> > 
> > 
> > Exactly.
> 
> I am doubtful.
> 
> What is the MN going to do with the address that is conveyed 
> by HAck/FBAck?  If it is going to assign it on an interface, 
> or use it in the src field of packets it originates, then it 
> is not enough to convey addresses, but the lifetimes 
> associated with them are necessary too. HAck/FBAck don't 
> convey lifetimes associated with addresses.
> 
> This is difficult to manage.  It is already not obvious for 
> MN to distinguish between stateless/stateful based on RA 
> information...

True. IP address alone may be insufficient here. The problem really is this - DHCP gives you a bunch of other parameters with the IP address. If we assume "assigned address" is a DHCP address, there is a need to account for all the parameters associated with it. But then, it gets a little sticky doing DHCP on behalf of a client that hasn't sent any DHCP messages - DHCP client proxies aren't well defined. If you want the NAR to be a proxy for the MN, the NAR needs to generate a client ID on behalf of the MN for the DHCP server. You really want the NAR to wash its hands off IP address management once it conveys the address to the MN - in other words, it is not good to have the NAR renew or maintain lifetimes, etc. So, the NAR now has to convey all the parameters to the MN, so that the MN can manage its own IP address from then on. 

To add to the complexity, we can add one more thing - if the MN is supposed to be securing DHCP messages (who does that?!), it gets ugly really fast. 

We can take one of two approaches here - say that only autoconfiguration is standardized in FMIP and make the HAck and FBAck extendable for using vendor specific info for people who need DHCP to do their own thing :) Or, if we want to accommodate DHCPv6, some thought needs to go into this to do it right. 

Vidya

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Aug 2005 14:16:45 +0200

Narayanan Vidya-CVN065 wrote:

> True. IP address alone may be insufficient here. The problem really is
> this - DHCP gives you a bunch of other parameters with the IP address.
> If we assume "assigned address" is a DHCP address, there is a need to
> account for all the parameters associated with it. But then, it gets a
> little sticky doing DHCP on behalf of a client that hasn't sent any DHCP
> messages - DHCP client proxies aren't well defined. If you want the NAR
> to be a proxy for the MN, the NAR needs to generate a client ID on
> behalf of the MN for the DHCP server. You really want the NAR to wash
> its hands off IP address management once it conveys the address to the
> MN - in other words, it is not good to have the NAR renew or maintain
> lifetimes, etc. So, the NAR now has to convey all the parameters to the
> MN, so that the MN can manage its own IP address from then on.
> 
> To add to the complexity, we can add one more thing - if the MN is
> supposed to be securing DHCP messages (who does that?!), it gets ugly
> really fast.
> 
> We can take one of two approaches here - say that only autoconfiguration
> is standardized in FMIP and make the HAck and FBAck extendable for using
> vendor specific info for people who need DHCP to do their own thing :)
> Or, if we want to accommodate DHCPv6, some thought needs to go into this
> to do it right.

I think that if the "assigned address" field is removed from the
HAck/FBAck (in the spec) then the inner workings of the proactive
approach will certainly be influenced.

That may mean that the proactive approach can be used only with
vendor-specific extensions (that are not yet specified).

If only the stateless autoconf is taken into account by FMIP then
probably only the reactive approach may continue to work.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Aug 2005 08:41:11 -0700

Vidya,

FMIP is asking DHCP to provide the next link address information (meaning
the address, lifetime, and everything else needed to manage the address) off
the link on which the address is valid. DHCP wasn't designed to do that.

One possibiity might be to establish a "virtual link" between the NAR and
the MN via a tunnel prior to the handover, so that the MN can perform the
DHCP signaling itself. The other, as you mention below, is for the NAR to
act as a DHCP proxy, but that would require doing something that isn't
really in the base design, so we would probably need to co-ordinate that
with the DHCP WG.

            jak

----- Original Message -----
From: "Narayanan Vidya-CVN065" <[email-masked]>
To: "Petrescu Alexandru-AAP021" <[email-masked]>; "Syam
Madanapalli" <[email-masked]>
Cc: "Soliman, Hesham" <[email-masked]>; "Junghoon Jee"
<[email-masked]>; <[email-masked]>; "James Kempf"
<[email-masked]>; "Koshiro MITSUYA" <[email-masked]>
Sent: Friday, August 12, 2005 4:48 AM
Subject: RE: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FN
A)

> True. IP address alone may be insufficient here. The problem really is
this - DHCP gives you a bunch of other parameters with the IP address. If we
assume "assigned address" is a DHCP address, there is a need to account for
all the parameters associated with it. But then, it gets a little sticky
doing DHCP on behalf of a client that hasn't sent any DHCP messages - DHCP
client proxies aren't well defined. If you want the NAR to be a proxy for
the MN, the NAR needs to generate a client ID on behalf of the MN for the
DHCP server. You really want the NAR to wash its hands off IP address
management once it conveys the address to the MN - in other words, it is not
good to have the NAR renew or maintain lifetimes, etc. So, the NAR now has
to convey all the parameters to the MN, so that the MN can manage its own IP
address from then on.
> To add to the complexity, we can add one more thing - if the MN is
supposed to be securing DHCP messages (who does that?!), it gets ugly really
fast.
is standardized in FMIP and make the HAck and FBAck extendable for using
vendor specific info for people who need DHCP to do their own thing :) Or,
if we want to accommodate DHCPv6, some thought needs to go into this to do
it right.

---

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Aug 2005 08:47:18 -0700

> probably only the reactive approach may continue to work.

I think stateless could work with predictive handover.

Using RtSolPrxy/PrxyRtAdv, the MN gets the subnet prefixes on the PAR,
autoconfigures an address prior to movement. When it arrives on the NAR, it
uses oDAD to confirm the address (or FNA if we decide to keep it).

There is of course an issue here of whether the predictive information is
really helping matters if the MN must do IP level movement detection after
it moves anyway, by RS/RA like DNA for example. In that case, the MN gets
the prefixes from the RA after it is on the NAR and could configure the
addresses right away on the NAR. Doing so on the old would save some time,
but the distinction between predictive and reactive gets a little thin here.
But if there is specialized link support for IP level movement detection
that doesn't require RS/RA, then having the predictive information could
help.

            jak

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 12 Aug 2005 11:18:57 -0400

> really in the base design, so we would probably need to co-ordinate that

Several building blocks of the MPA framework
(draft-ohba-mobopts-mpa-framework-01.txt) could be combined with FMIP6
for this purpose, specifically, pre-authentication phase and
pre-configuration phase.

Yoshihiro Ohba