> > > I'd say for connected and bound sockets, getsockname() would return
the
> > > correct topological source address.
> >
> > But that'd break the getsockname() function, which should return the
local
> > binding of the socket. If the socket is bound to a home address, that
> > address
> > should
gt; From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Samita
> > Chakrabarti
> > Sent: Monday, December 02, 2002 11:52 AM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Sub
>(section 5 and 6 rule 4). The MIPV6 API should also take care of
>choosing
>temporary address and non-temporary address from the application level.
>Also, there is a need to choose link-local or site-local address as
>source
>address (depending on the scope) for the MN
cal job.
> >
> > Thanks for your comments.
> > -Samita
> >
> > >
> > >
> > > > -Original Message-
> > > > From: Alper E. YEGIN [mailto:[EMAIL PROTECTED]]
> > > > Sent: Thursday, November 21, 2002 9:49
> > I'd say for connected and bound sockets, getsockname() would return the
> > correct topological source address.
>
> But that'd break the getsockname() function, which should return the local
> binding of the socket. If the socket is bound to a home address, that
> address
> should be returne
In your previous mail you wrote:
> That's what I was aiming for; a short and simple advanced api socket
> extension doc as a guideline for MIPv6 compatible applications.
The default address selection draft contemplates about such an API:
Implementations should provide a mec
In your previous mail you wrote:
> > Or, don't change the getsockname(), but instead call
> > mip_get_one_mobile_node() afterwards to identify if the address is bound
> > to a care-of address. Note that this binding can dynamically any time,
> > and subsequent mip_get_one_mobile_node(
In your previous mail you wrote:
I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API
document. The following requirements in MIPv6 spec indicates that there
is a need for Socket API which will allow the MIPv6 applications to
choose
COA as mobile node's source addr
In your previous mail you wrote:
What you did would work with what I stated too. After the kernel gets
done the getsockname could send back all data but I think we would need
a new api and options to the kernel?
=> as I wrote I used a "clone" of the getsockname() system call
(it was
In your previous mail you wrote:
Yes, the applications need to change to accomodate MobileIP.
=> this is my concern.
The goal should be to change them minimally.
=> a minimum greater than zero is not acceptable. IMHO the setsockopt()
solution is not what we need, and there is no easy alt
MAIL PROTECTED]]
> > > Sent: Thursday, November 21, 2002 9:49 PM
> > > To: Francis Dupont
> > > Cc: Samita Chakrabarti; [EMAIL PROTECTED];
> > > [EMAIL PROTECTED]
> > > Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to
> > > switch defa
> > Or, don't change the getsockname(), but instead call
> > mip_get_one_mobile_node() afterwards to identify if the address is bound
> > to a care-of address. Note that this binding can dynamically any time,
> > and subsequent mip_get_one_mobile_node() calls are sufficient to capture
> > the chang
nday, November 25, 2002 12:31 AM
> To: Bound, Jim
> Cc: [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: [mobile-ip] Re: Proposal for MIPv6 APIs to
> switch default source address selection
>
>
>
>
> >
> &g
sage-
> > From: Alper E. YEGIN [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, November 21, 2002 9:49 PM
> > To: Francis Dupont
> > Cc: Samita Chakrabarti; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]
> > Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to
>
> > In your previous mail you wrote:
> >
> >An alternative approach could be: If the application cares about
> >the source address, it can use the Mobile IP API to figure out which
> >ones are home address, which ones are care-of address, and than
> >explicitly "bind" the socket
essage-
> From: Samita Chakrabarti [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, November 24, 2002 11:59 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Proposal for MIPv6 APIs to switch default source
> address selection
>
>
>
> => in order to use the API, an application needs to be changed.
> So with only the API, the only way to influence the Co@/H@ choice
> is to change all common applications... So the API will get only
> very limited use and the smart user should still wait for a device
> to fulfill his needs.
>
t; Cc: Samita Chakrabarti; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to
> switch default source address selection
>
>
>
>
> > In your previous mail you wrote:
> >
> >An alternative approach could
[EMAIL PROTECTED]]
> Sent: Thursday, November 21, 2002 6:15 PM
> To: Alper E. YEGIN
> Cc: Samita Chakrabarti; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to
> switch default source address selection
>
>
> In your pr
as should have IPv6 WG.
/jim
[Honor, Commitment, Integrity]
> -Original Message-
> From: Alper E. YEGIN [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 21, 2002 1:33 PM
> To: Samita Chakrabarti
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Proposal
s api draft.
/jim
[Honor, Commitment, Integrity]
> -Original Message-
> From: Alper E. YEGIN [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 21, 2002 9:56 AM
> To: Samita Chakrabarti; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re:
]
> -Original Message-
> From: Francis Dupont [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 21, 2002 9:40 AM
> To: Samita Chakrabarti
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: Proposal for MIPv6 APIs to switch default source
> addres
In your previous mail you wrote:
I see. When the mobile node has more than one pair of
home_address-care_of_address, then it won't really know which
one to pick. So, maybe, instead of exporting all this information
to the apps and giving them the control, it might be better
to en
> In your previous mail you wrote:
>
>An alternative approach could be: If the application cares about
>the source address, it can use the Mobile IP API to figure out which
>ones are home address, which ones are care-of address, and than
>explicitly "bind" the socket to the desir
In your previous mail you wrote:
An alternative approach could be: If the application cares about
the source address, it can use the Mobile IP API to figure out which
ones are home address, which ones are care-of address, and than
explicitly "bind" the socket to the desired address. I
In your previous mail you wrote:
> => the problem of this API is that it is not useful because nobody wants
> to change all applications to use it. So we need also a way to change
I am not sure why you are saying that all applications needs to change
for this.
=> in order to use
Hi Samita,
> I did take a look at the draft that you folks have for mobile IP
> applications.
>
> That draft gives a general overview of mobile application usage, but I
> am
> addressing a different scope (which is more equivalent to having an
> extension
> to IPv6 advanced Socket API document fo
Hello Alper,
"Alper E. YEGIN" wrote:
>
> > I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API
> > document. The following requirements in MIPv6 spec indicates that there
> > is a need for Socket API which will allow the MIPv6 applications to
> > choose
> > COA as mobile node's
Francis Dupont wrote:
>
> In your previous mail you wrote:
>
>I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API
>document. The following requirements in MIPv6 spec indicates that there
>is a need for Socket API which will allow the MIPv6 applications to
>cho
> I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API
> document. The following requirements in MIPv6 spec indicates that there
> is a need for Socket API which will allow the MIPv6 applications to
> choose
> COA as mobile node's source address (in a visited network), while
> d
In your previous mail you wrote:
I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API
document. The following requirements in MIPv6 spec indicates that there
is a need for Socket API which will allow the MIPv6 applications to
choose COA as mobile node's source address
I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API
document. The following requirements in MIPv6 spec indicates that there
is a need for Socket API which will allow the MIPv6 applications to
choose
COA as mobile node's source address (in a visited network), while
default
address
32 matches
Mail list logo
