Subject: RE: [Tsvwg] EndPoint and Association Address conflict

From: [email-masked]
Date: Mon, 29 Apr 2002 17:02:10 +0300

Hi all!

	See my comments below...

> -----Original Message-----
> From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 29. April 2002 15:37
> To: Tuexen Michael
> Cc: Jacob Heitz; Khan, Mohammad; [email-masked]'; Pillai, Hari
> Subject: Re: [Tsvwg] EndPoint and Association Address conflict
> 
> 
> Tuexen,
> 
> It is absurd, because it is an artificial restriction without merit
> and without parallel in TCP.  Removing (ignoring) this sentence causes
> no problems for the protocol.  Also, the peer has no way of detecting
> or enforcing this restriction, making it even more absurd.

	I don't think it is absurd at all. You need to have a group of IP addresses that "go together". Otherwise, how could you know which addresses you should include in the INIT ACK when an INIT chunk hits one of those addresses/port? Or when the user tells you to establish a new association from endpoint X...

	And the restriction is completely logical... Otherwise, if you receive an INIT going to IPA/PortZ, and that address/port pair is part of two different endpoints, how can you know to which one it goes?

	As far as I understood from this long thread, Brian, you are saying that it is legal to have endpoint E1: [(IPA, IPB); Port 1024], and endpoint E2: [(IPA, IPC); Port 1024] (please, correct me if I'm wrong). Then, you receive an INIT (or any other chunk, but let's say it is an INIT to make things clearer), from endpoint EZ, going to IPA/Port 1024... Should you include IPA, IPB, or IPA, IPC?... That's why you cannot include the same address/port pair in two different endpoints...

	In my understanding, an endpoint is basically a port plus some of the host's addresses, and it is mainly used when responding to datagrams that don't go to any established association. It is kind of listener socket... When you receive something whose source/destination address/port is not part of any existing association, then you try to see if that datagram goes or not to any of the endpoint that might be "listening" to the destination address/port of the datagram (our source address/port). If there is any endpoint listening at the port to which the datagram was sent, then you process the datagram (as stated in section 8.4 of RFC 2960).

	And now, regarding the AddIP issues... Let me show you the way I see all this...

	In my understanding, when you establish a new association, you start with the "default" set of addresses, i.e., all of the addresses of the endpoint. Later on, you can delete some of those addresses in *some* associations, stopping using them as your source addresses. Also, if the endpoint adds new addresses, then, you can add those addresses to the associations that were created inside that endpoint...

	Basically, an association created from your endpoint E1, CAN NOT have more addresses than the ones that currently E1 has, but it CAN have less.

	In the examples given by Randall when you add a new card, I think that you have a problem if you bind to INADDR_ANY... That's because you don't know if the peer supports or not AddIP... If it doesn't, and you are not able to add the new addresses, you might end up receiving an ABORT from you peer if you use the newly added address.

	So I think that the associations should have knowledge about which addresses they can use as source address, because they might not always be all the addresses of the endpoint to which they belong... :-/

	And the point is not only that I might not be able to add the address, I might simply not want to do it. If it cost more money to send packets through the new address, then I might not want to use it at all, even though I could...

	So, associations can (independently) use AddIP extension to delete a source address in any case (except if it is the last one, of course). BUT, associations might only be able to add a new source address if the endpoint is using it. So, in my mind, I make a distinction between adding/deleting an address to/from an endpoint, and adding/deleting an address to/from a particular association... If you add an address to an association using ASCONFs, you MUST previously add it to the endpoint. If you delete an address from an endpoint, you SHOULD try to delete it previously using ASCONFs for all the associations using that source address and belonging to the endpoint to which the address is about to be added (i.e., also using the source address and the source port of the endpoint). I'm not sure if it should be a MUST or a SHOULD. If you are really unplugging the network card, then it doesn't matter since you are not really going to use that address any more either for sending or rec!
eiving. If you are simply doing it because you want to modify the endpoint (but the address is still physically working), then you should take care of what you are doing... :-/

	Summarizing:

	- An endpoint can use a subset of the source addresses of the host.
	- An association, can use a subset of the source addresses of the endpoint to which it belongs.

	I would very much appreciate comments about this mail...

	Thanks a lot!

	BR Iván Arias Rodríguez

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

---

From: Randall Stewart <[email-masked]>
Date: Mon, 29 Apr 2002 12:55:12 -0500

Ivan:

My only comment is ..

Yes, I agree with what you are saying and think you have
stated it quite well :>

R

[email-masked] wrote:
>         So, associations can (independently) use AddIP extension to delete a source address in any case (except if it is the last one, of course). BUT, associations might only be able to add a new source address if the endpoint is using it. So, in my mind, I make a distinction between adding/deleting an address to/from an endpoint, and adding/deleting an address to/from a particular association... If you add an address to an association using ASCONFs, you MUST previously add it to the endpoint. If you delete an address from an endpoint, you SHOULD try to delete it previously using ASCONFs for all the associations using that source address and belonging to the endpoint to which the address is about to be added (i.e., also using the source address and the source port of the endpoint). I'm not sure if it should be a MUST or a SHOULD. If you are really unplugging the network card, then it doesn't matter since you are not really going to use that address any more either for sen!
 ding or
> rec!

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 29 Apr 2002 13:01:57 -0500

Hi, Ivan:

....snip....
>         - An endpoint can use a subset of the source addresses of the host.

Yes.

>           endpoint to which it belongs.

No, this is incorrect. 

All associations coming out of an endpoint MUST use all the source
addresses of the endpoint all the time. However, the address set of the
endpoint can change over time (by adding or deleting IPs). Whenever that
happens ALL the existing associations coming out of the endpoint MUST be
updated to the new address set (this is why we have ASCONF exchanges).
Moreover, there are rules over how the address set of the endpoint can
be changed. That is what I sent out in my previous email.

regards,
-Qiaobing

---

From: Jon Grimm <[email-masked]>
Date: Mon, 29 Apr 2002 12:35:06 -0500

Ivan/All
	
	I think something that needs to come out of this discussion are
scenarios and mandatory behavior in those scenarios (or why flexibility
is allowed if not mandatory behavior).  Its a little disturbing that a
similar 'what is an endpoint?' discussion seems to pop up again every so
often.  (e.g.bindx discussion last Sept in
ftp://ftp.ietf.org/ietf-mail-archive/tsvwg/2001-09.mail ) and still does
not seem to be completely clear even to those following SCTP closely
over the last year.  

For each of the following scenarios,

1) A new address is to be added an endpoint. (manual) 
2) An address is to be deleted from an endpoint.  (manual)
3) A new NIC/address is configured and an endpoint is bound to all
(auto)
4) An address bound is brought down (no longer available) (auto).   
5) An address bound is brought down for maintenance and then brought
on-line again. (auto)

consider each of the following subcases (assuming multiple associations
under an ep).  

a) All Peers have ADD-IP.  
b) No Peers have ADD-IP.
c) A subset of Peers support ADD-IP.

What happens?  

Another comment:
Dropping down a little bit into the Sockets API for illustration:

Depending on one's interpretation of endpoint, what is the endpoint for
the association of a peeled-off UDP style socket or for that matter an
'accepted' TCP-style socket.  If the strict interpretation of the
endpoint is kept.. wouldn't an ADD-IP on the child sockets (peeled off
or accept TCP) affect the local endpoint of the parent socket?  Or vise
versa, should an ADD-IP on a TCP-style listening socket, affect the
accepted sockets?  If yes, was this expected?  If no, does the original
definition of endpoint still hold?  

Even if each expected behavior does not get spelled it, it would be nice
for the SCTP Sockets API I-D to clarify the relationship between a
socket and an endpoint, so implementors can at least infer what the
intended behavior should be.   

Best Regards,
Jon Grimm

>         So, associations can (independently) use AddIP extension to delete a source address in any case (except if it is the last one, of course). BUT, associations might only be able to add a new…
 di!
!
ng or receiving. If you are simply doing it because you want to modify the endpoint (but the address is still physically working), then you should take care of what you are doing... :-/

---

From: Randall Stewart <[email-masked]>
Date: Mon, 29 Apr 2002 13:35:19 -0500

Jon:

a couple of comments :>

> not seem to be completely clear even to those following SCTP closely

I agree.. it is a discussion that seems to NEVER end :>

> c) A subset of Peers support ADD-IP.

Where are you proposing putting these examples? I think some
text is needed for clearification but I am not sure that a protocol
spec is where you illustrate all these different examples...

> accepted sockets?  If yes, was this expected?  If no, does the original

In my view the ADD-IP is done against the listening type endpoint. So
in the case of connected and/or peeled off associations they are
a different critter. In some ways they have formed a "new" endpoint. But
a interesting thing about them is they CAN NOT listen. So maybe in
this case Brian's adding an address to the association is the right
approach. They can NEVER receive a new association.. only the single
listner (in the TCP or UDP case) can do that. 

So a peeled off or "connected" socket with only one association may
well be a candidate to do an add-ip on an association basis.. but not
on the listening endpoint or a UDP model grouping of associations...

> intended behavior should be.

Hmm this may be the best place for this information since it will
be informational..

R

---

From: Randall Stewart <[email-masked]>
Date: Mon, 29 Apr 2002 13:44:29 -0500

> >           endpoint to which it belongs.

Sorry it IS correct. Forget add-ip.. if you say the above then
a basic bound-all endpoint begins to violate this new "rule"
when you plug in a new card and ifconfig it up.

There is no reason that an endpoint can't have associations that
end up using a sub-set of the endpoints addresses. And I have
shown in my previous email what will happen if this endpoints
silly peer attempts to INIT to the NEW address... It all
works out..

R

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 29 Apr 2002 21:54:59 +0200

Dear all,

since we agree on the end-point terminology we can go further.

See my comment below.

Best regards
Michael

On Monday, April 29, 2002, at 08:44 PM, Randall Stewart wrote:

>>>         - An association, can use a subset of the source addresses of 
>>> the
>>>           endpoint to which it belongs.
>>
>> No, this is incorrect.
>>
>
I'm not sure what the term 'an association can use a subset of IP 
addresses' means.
I'm interpreting it as 'use the address in an INIT or INIT-ACK chunk'. 
Taking that
definition, I think, the address scoping of IPv6 (and IPv4) will reduce 
the set
of used IP addresses possibly to a proper subset of the address of the 
end-point.
Is this correct?
>>>         I would very much appreciate comments about this mail...
[email-masked]

---

From: Jon Grimm <[email-masked]>
Date: Mon, 29 Apr 2002 14:44:45 -0500

Thanks for the remarks, Randy. 
 I have a few comments still below.  Thanks, Jon

> spec is where you illustrate all these different examples...

In some I-D,of course.   I see you are considering the Sockets API I-D,
yes this could work for me as an appendix there.  Given this latest
round of discussion, folks may wildly disagree, but I'm coming from the
angle that I just want it captured.  ;-)

> on the listening endpoint or a UDP model grouping of associations...

Has this gone full circle then?   This sounds more like you are always
doing add-ip on associations.   Or you are really always doing add-ip on
(Brian's or Ivan's ??) individual communication endpoints that belong to
a grouping (group of 1 (peeled off) or many (udp style))?  

Consider two cases:    
1)  If not bound-all, and an address is added via bindx.. I'd want the
bindx to apply to the listening endpoint, as well as the associations
currently grouped under that socket, but not the peeled-off socket.   
2) If however, if the original socket was bound-all and a new interface
is configured, I'd want to this new information to propogate both to the
original listening socket and any peeled off sockets.   

Do these make sense?

A related question:  should Add-ip happen on associations waiting in the
TCP-style accept queue?   manual bindx()?  auto INADDR_ANY??

> Hmm this may be the best place for this information since it will

Sure.  If thats were folks want it, as long as gets agreed on and
captured somewhere.  

Thanks,
Jon

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 29 Apr 2002 14:19:16 -0500

...
> when you plug in a new card and ifconfig it up.

Randy,

See if I understand what you are trying to say here. Say, you have the
following "bound-all" endpoint with an assoc to a peer E2

host has: IPA and IPB
     E1             A1     E2
[IPA,IPB:Port1] <-------> [...]  /* you use all addr in E1 */

you then plug a new nic and ifconfig it up with IPC, 

host has: IPA, IPB, and IPC
     E1             A1     E2
[IPA,IPB:Port1] <-------> [...]  /* you use still all addr in E1 */

you attempt to update E1 but add-ip procedure and has succeeded

host has: IPA, IPB, and IPC
     E1'                A1'    E2
[IPA,IPB,IPC:Port1] <-------> [...]  /* you use all addr in E1' */

If add-ip did go through

host has: IPA, IPB, and IPC
     E1             A1     E2
[IPA,IPB:Port1] <-------> [...]  /* you use still all addr in E1 */

So, I don't see any conflict between the rule and your case. 

> silly peer attempts to INIT to the NEW address... It all

I agree with you that forcing the silly peer out and to restart is a
good alternative in this corner case.

-Qiaobing

---

From: Randall Stewart <[email-masked]>
Date: Mon, 29 Apr 2002 15:22:44 -0500

> good alternative in this corner case.
Thinking about this with a private email discussion I realize
the address add restriction is the peers address... maybe we
need to expand that to the local addresses too. this way 
the restart routine would catch it.. abort the silly peer and
we don't have to worry about this case..

R

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 29 Apr 2002 22:11:01 +0200

Dear all,

one possibility to capture this stuff is in an separate ID. It could
deal with such terminology stuff and usage stuff for AddIP. Maybe
an applicability statement or BCP. Don't know, but it could life for
some time as an ID and become an RFC later on.
If this seems a good idea I could try to write up some text ...

Best regards
Michael

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 29 Apr 2002 18:04:07 -0500

Hi, Randy,

I think we are still using slightly different endpoint definitions (as
you also realized below).

...
> 
> I still view it as adding to an endpoint but I think we must
> re-think about this... I put this down in a private email discussion
> but I think I will put it out here now ... even though the
> thoughts are only partially baked :>
> 
> We have basically 4 types of endpoints/sockets (note I think of
> an endpoint as a socket aka open FD).

I think of an endpoint as an abstract logical entity (as dryly defined
in RFC2960). I see three levels of address sets involved here:

Level 0: host addr set "S" = all the network addresses assigned to a
host (host is logically represented by a single OS instance). A host can
harbor multiple sockets/open FDs.

Level 1: addr set bound to a socket/open FD "s" = a subset of S bound to
the FD (this is the logical representation of an SCTP stack). An open FD
can harbor multiple endpoints. But some implementation, for simplicity
reason, may support only one endpoint.

Level 2: addr set of an endpoint "e" = yet a subset of "s". This is the
set of addresses actually used (or to be used) in an association.

In summary, e <= s <= S.

All my previous discussions were based on the "e" definition (including
the rules I proposed). 
Therefore, the following statement from Ivan 

  - An association, can use a subset of the source addresses of the
    endpoint to which it belongs.

becomes correct if Ivan's "endpoint" here implies a socket/open FD, but
incorrect if the "endpoint" here is defined as "e" above.

I will think more about the socket implications.

-Qiaobing

> 
> Now we have:
> 
> 1) A UDP model socket/listener that A) accepts new associations and
>    has some number of associations under it (fanned out is the term
>    I think Qiaobing used).
> 
> 2) A TCP model listener. This guy will have NO associations under
>    it accept maybe onces waiting to be accepted ... nothing can
>    happen on those though.. until AFTER they are accepted.
> 
> 3) Accepted and or peel'ed off ones.. these are a single association.
> 
> 4) A TCP model connect() caller. This guy can NOT accept any.. but is
>    going to have a single "association" to a peer... note this may
>    be (in the end) to a <1> or <3> type guy.. it does not matter.
> 
> Now lets look at each case..
> 
> First, an easy one, <3> is something that can NEVER get any new
> associations. INIT's don't go to it... they go to whoever was the
> listner... so in this case this association COULD have add-ip go
> against it. .thoughts/notes...{I believe in our implementation of add-ip
> this
>                                guy MAY auto-add IP if it is setup via an
>                                sockopt to do it.. default may be on
> especially
>                                if the parent (listener) is bound all
>                                }
> 
> Now lets look at another easy one.. <4> the connector.. this guy
> IS NOT LISTENING.. it TOO can't get a INIT in.. an ABORT() would be
> sent back... At the termination of its association, however, it MAY
> do a listen() call..  so here we would ADD the address to the endpoint
> (if it was turned on socketopt wise to do so..) and the attempt if
> possible to add it to the peer.
> 
> Now this leaves case <1> and <2>. The only real difference between
> these guys is that we have one that has a cluster of associations
> tied to it.. the other does NOT. Now we here ADD the address to the
> endpoint. For <2> we are done.. when the next INIT comes in the new
> association will form... and we are ok... For <1> new associations
> will use the new address.. (all of this assumes that the option
> to add automatically is enabled.. for bind-all this is probably
> the default.. it may not be for sub-set bound). Now for the
> existing "fan" of associations we would individually attempt to
> add the address to them..
> 
> Now for the big question .. what happens if we get our silly endpoint
> (peer) that sends an INIT while holding an association to us (either
> a TCP one or a fanned out one). Well some observations:
> 
> a) First you must be able to find the old associations, if you
>    can't then your INIT collision and RESTART code is NOT working.
> 
> b) When you find the "old" associations it is going to look like
>    a restart condition... especially for <1> since you locate the
>    endpoint (and you have added the address here hopefully) and then
>    you look for the association via one of the peers addresses. For the
>    TCP model you also must switch the socket you are associated with
>    in this hunt... hmmm lets look at both sides..
>     - If you find it then you would actually go through the
>       restart scenario as long as the peer used the same addresses
>       it would appear to be a restart.. this would be very interesting
>       and of course the peer would get very messed up I bet... but its
>       a silly endpoint anyway.. in the end the old association would
>       die, one way or another... Now if we add a restriction that we
>       can't add any new addresses on either side (aka like our current
>       peer can't add new addresses) then no problem.. we would ABORT()
>       with new addresses...
>     - If you can't find it then what would happen is when the COOKIE
>       arrives you could since you could look at all your addresses
>       and validate that a collision is not at hand... and then send
>       an abort...
> 
>    Pesonnely I prefer the no new addresses on either side during a
>    collision.. this solves the problem as long as you can locate your
>    associations.. which I think you should be able to..
> 
>  Well .. there are some of my 1/2 baked thoughts... need to mull on
>  them a bit more..
> 
> R
> 
> --
> Randall R. Stewart

---

From: Randall Stewart <[email-masked]>
Date: Mon, 29 Apr 2002 19:02:32 -0500

A comment in line and then some more thoughts..

> set of addresses actually used (or to be used) in an association.

I don't get your Level 2 definition.. it is unclear to me
what you are saying...

> I will think more about the socket implications.

This may help.. think on what I have said about socket descriptors (or
fds if you like) and what type of socket api model we have..

Now I have done a bit more thinking on this. The corner case that
we were worried about was this (if I remember right):

Host A                                          Host Z
IP-A/IP-B                                       IP-Z
(An UDP model Endpoint
 Listening on Port 2222)
        IP-A:Port-2222<-----------------INIT(From IP-Z:Port 3333)
        ----------INIT-ACK(IP-A,IP-B:Port 2222)-------->
        <--------------COOKIE-ECHO----------------------
        ----------------COOKIE-ACK---------------------->

            Now at this point A-1 is up.

Now along the line we do

ifconfg New-Intf IP-C

and magically do

--------------ASCONF(ADD-IP:IP-C)------------------------>
    <---------------------OperationalError(Unknown Chunk ASCONF)-----

So here we have a potential problem...

                    now our silly peer does

 <------------------------IP-C:2222 INIT(IP-Z:Port 3333)

What do we do?

 --------INIT-ACK(IP-A,IP-B,IP-C: Port 2222)---------->IP-Z:Port
3333--->

Now what we have forgotten about is what our silly endpoint is going
to do. 

The SCTP stack on Host-Z must look to see if a collision is
happening.. this is required in RFC2960. So what happens will depend
on where the INIT-ACK is sourced from..

If by chance its source is IP-A or IP-B ... guess what? the lookup
at Host-Z will return the OLD association which is NOT in a COOKIE-WAIT
state.. so what will Host-Z doe? Discard the INIT-ACK... This will
happen again (i.e. the INIT-timer will expire on Host-Z and this will
then repeat until we fail).... No problem..

Now what happens if by chance it IS sourced from IP-C? We find the
newly forming association. Now it goes throughs its procedures 
to attempt to gather all the valuable goodies out of the INIT-ACK.
In the process it must load its peers addresses to the association.
And here is where it SHOULD detect the other association. I know
in our implementation one of the first things I do when loading
an address is do a lookup on the address I am loading.. I want
to make sure it is in the association only ONCE. In the process
I get back the association ... one of the checks I do is verify
that it is the same association that I am working on loading 
address to .. if not.. guess what ? I detect the error and
bail out.. dropping the INIT-ACK... so .. same result.. we continue
to send out INIT's and drop the result.. thus the IP-C association
just never forms..

Now is this clear in any document that you must look for addresses
as you load them.. no its not specified since it is an implementation
detail. I will admit it is an important one.. Should it be documented
that you SHOULD attempt to detect this? Maybe but I am not sure 
where this would fit..

But in the end my basic premise is that if the implementation is
coded right the silly endpoint will self-correct and NOT bring up
this strange association.

I don't think we can dis-allow adding an new address... otherwise
a true restarting association could not come up if I just added
an address until it aborted ... so I don't like that idea...

Let me also note .. say my implementation hits a peer that does
NOT catch this.. guess what.. the same code is going to run to
load the addresses from the cookie.. It too will find this 
double association setup and drop the cookie...

So my contention is that this corner case is NOT an issue if
the address loading is done properly by the implementation...

R

---

From: Randall Stewart <[email-masked]>
Date: Mon, 29 Apr 2002 15:50:25 -0500

Now we have:

R

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 29 Apr 2002 20:02:21 -0500

R, 

A couple of comments...

Randall Stewart wrote:
...
> So here we have a potential problem...

At this point, would our local stack (I am avoiding to use endpoint
here) actually start to use IP-C as the source addr in any outbound
packets in the current association? If so, that would trigger an abort
from the peer and kill the current association. If not, then strictly
speaking, IP-C has not yet been added to the local **endpoint** that the
current associaiton is using. It has only been made available to the
local stack for future use. 

>  --------INIT-ACK(IP-A,IP-B,IP-C: Port 2222)---------->IP-Z:Port

When the local stack does this, it starts to manage two logically
different local endpoints - the one used by the old association that has
only IP-A and IP-B; the other is intended for the new association, as
advertised in this INIT-ACK, that has IP-A, IP-B, and IP-C.

To have multiple logical endpoints here is not a problem. But the
problem is that they are sharing IP-A and IP-B. This not only goes
against RFC2960 definition, but also becomes the root cause that opens
the door for the "corner case" and potential danger of other "duplicate
association" cases.

Of cause, as you showed below, if a solid implementation is vigorously
checking and double-checking for dup associations at multiple points
during the initiation process, you may eventually weed them out. But I
am not sure about just relying on the implementation to catch dup
associations.

-Qiaobing

---

From: Randall Stewart <[email-masked]>
Date: Mon, 29 Apr 2002 20:41:21 -0500

> advertised in this INIT-ACK, that has IP-A, IP-B, and IP-C.

No it is managing two different assocaitions.. not endpoints...

You are always allowed to have an ENDPOINT with a set of
addresses... Associations have to be able to use subsets
of the addresses... period.. otherwise forget IPv6..

> the door for the "corner case" and potential danger of other "duplicate

There is no corner case...there are incorrect implementations :> but
I don't see a corner case any more..

> am not sure about just relying on the implementation to catch dup

I think we have a fundamental misconnect here.. you keep talking
of splitting endpoints.. I don't see it. 

R

---

From: Randall Stewart <[email-masked]>
Date: Tue, 30 Apr 2002 08:52:05 -0500

Jon Grimm wrote:
> I can't see if it matters or not, but how about the delete-ip case?  If
> an endpoint has multiple associations and a subset of the associations
> support delete-ip.   What should happens to the endpoint?  Is the
> address really removed from the endpoint?  There are associations still
> using that address removed from some of the addresses.  I can see where
> I might want to keep the address in the endpoint until all users of the
> address have either ACKed the delete or have terminated.  In this case,
> I wouldn't want to allow a new endpoint to form with that deleted
> address.  Is this warped thinking?
> 
Jon:

well let see... I think the way we handled this is we DID
remove it from the "endpoint" or listener... that way you
will NOT accept new INIT's to this.. of course if the 
address is truely removed from the system its a MOOT point :>

Now each association has its own list of addresses that are
in this "present and not deleted state" or "added but not completed"
state.
That way if somehow a packet came in to that address we would
locate the right association.

I think the big thing here that I have not stated is I don't
believe we allow you to add/delete an IP address to a association.

You do a sctp_bindx() against an endpoint yes.

You have flags that say (default is on in most cases) DO ASCONF
if you can.. So you get this behavior on all your fanned out
associations.. but if I am adding an address and some association
under my endpoint can't.. no big deal it just goes on a negative
list saying.. don't use this address. (And we are in the kernel
so we DO control the IP address that goes on the wire... if you
can't control this address you are probably in rough shape and
unable to do add-ip .. the more I think about it... of course
if you can't control your IP address your stack is kinda broken :>)

But you CAN'T say ... add/delete this address to association X under
this endpoint.

Now for the "connected/peeled-off" socket you can do this .. since doing 
a sctp_bindx() against the connected socket WOULD add it to the
association.. but this of course does NOT change the listening
endpoint... so it has no ramifications against future INIT's that
arrive at the other endpoint that did NOT do a sctp_bindx() on the
address.

R

> 
> <snipped everything else>

---

From: Jon Grimm <[email-masked]>
Date: Tue, 30 Apr 2002 10:28:22 -0500

Thanks Randy,
	I think I see where you are coming from through the examples.

>>>Qiaobing Xie wrote:

[snipping a bunch]

> locate the right association.

I think this is what I was looking for.. it looks like it is possible 
for the non-delete-ip association to continue using the address 
(assuming it is not removed from the system).   In this case, the 
association would be using a superset of its endpoints current address 
set.

> arrive at the other endpoint that did NOT do a sctp_bindx() on the

Yeah, but this is where I get a little picky.  An association is a 
function of two endpoints.. a local and a remote.   What is this peeled 
off association's endpoint?  I'm guessing this is why you've migrated to 
talk about listener, as opposed to endpoint??  ;-)   To say an 
association doesn't have an endpoint seems a little odd.  If your 
perspective says that the peeled-off association belongs to a different 
endpoint, then this really becomes just an API implementation issue, 
since any association under an endpoint could migrate to another socket. 
  The association is only loosely tied to the listener endpoint by the 
socket.

Whew, enough of this for me.   I really just wanted to figure out what 
was allowed and what wasn't.   I think I'm there! (assuming I 
interpretted your comments above correctly).   I'm guessing folks will 
still use the endpoint term loosely, but at least we can nail down 
protocol (and possibly Sockets) behavior.

Thanks again,

jon

---

From: Jon Grimm <[email-masked]>
Date: Tue, 30 Apr 2002 08:22:39 -0500

Best Regards,
Jon