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

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Thu, 11 Aug 2005 14:05:04 -0500

> > Could anyone please explain what "assigned addressing" is.
> 
> Assigned address means NAR provides the address (NCoA) for MN 
> instead of MN constructing the NCoA from the prefix and 
> interface ID. NAR can be maintaining a pool of addresses from 
> which it assigns an address to MN through HAck, which finally 
> will be delivered in FBAck. May be, NAR can also ask DHCPv6 
> server to get an address for MN's 
> NCoA.
> 

NAR having a pool of addresses seems ok to assume. However, DHCP causes some concern. Are you implying that the NAR is doing DHCP on behalf of the MN - because, the MN in this case, does not send a DHCP Discover or any DHCP message for that matter. To me, it seems like this should be outside the scope of FMIP - having an option of conveying an IP address in the HAck seems reasonable - but there seems to be no need to describe the methods in which the NAR acquires an IP address for the MN. 

Vidya

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

---

From: Syam Madanapalli <[email-masked]>
Date: Fri, 12 Aug 2005 13:55:49 +0530

> NAR having a pool of addresses seems ok to assume. However, DHCP causes some concern. Are you implying that the NAR is doing DHCP on behalf of the MN - because, the MN in this case, does not send a…

Exactly.

-Syam

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Aug 2005 12:02:24 +0200

Syam Madanapalli wrote:

>>> instead of MN constructing the NCoA from the prefix and interface
>>> ID. NAR can be maintaining a pool of addresses from which it
>>> assigns an address to MN through HAck, which finally will be
>>> delivered in FBAck. May be, NAR can also ask DHCPv6 server to get
>>> an address for MN's NCoA.
>>> 
>> 
>> NAR having a pool of addresses seems ok to assume. However, DHCP
>> causes some concern. Are you implying that the NAR is doing DHCP on
>> behalf of the MN - because, the MN in this case, does not send a
>> DHCP Discover or any DHCP message for that matter. To me, it seems
>> like this should be outside the scope of FMIP - having an option of
>> conveying an IP address in the HAck seems reasonable - but there
>> seems to be no need to describe the methods in which the NAR
>> acquires an IP address for the MN.
>> 
> 
> 
> 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...

Alex

---

From: Syam Madanapalli <[email-masked]>
Date: Fri, 12 Aug 2005 22:12:14 +0530

[cut]
> HAck/FBAck don't convey lifetimes associated with addresses.

Isn't this problem persists irrespective of how the addresses are pooled
(DHCP, Manual, Autogeneration) in the NAR ?