Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-addip-sctp-11.txt

[Randall Stewart <[e-mail]>]

Salvatore Loreto wrote:
> Hi Michael,
>  
> sorry but if an INIT sender receives an INIT ack from a different Address
> that can't be a problem?

Nope...

Here an example in a NON-Mobile type case that is perfectly valid..

Consider the following two hosts..

+========+                        +========+
| (IP-A1)+<----/cloud ISP1 /----->+(IP-Z1) |
| host-a |                        | host-z |
| (IP-A2)+<----/cloud ISP2/------>+(IP-Z2) |
+========+                        +========+


Now.. lets say that the admin on each system
niavely setup the routing tables to add default
routes out to each of the two ISPs...

Linux allows multiple default routes if I remember
right.. FreeBSD you have to turn on RADIX_MPATH in
the KAME implementation..  Lets also assume
that we do not have the patch for alternate
routing (for a discussion of this see under
the downloads tab at http://www.sctp.org about
why you need alternate routing).

Now in this case both sides will use the default route
that is FIRST.. and lets say on one side the admin typed

route add default A1-ISP1
route add default A2-ISP2

and the other the admin typed

route add default Z2-ISP2
route add default Z1-ISP1

Now A binds port 9000 and Z binds port 10000 and
binds all addresses. A initiates an association to
IP-Z1

so you get:

------TO:IP-Z1[INIT(IP-A1, IP-A2) FROM:IP-A1---->

Since the default route for IP-A1 will point out the
interface of A1, we will do the proper src addr selection
and pick up the outbound interface that is bound to
the address...

The peer will answer:

<-----TO:IP-A1[INIT(IP-Z1, IP-Z2) FROM:IP-Z2-----

And will route it out over ISP-2.. since this is the
"first" default route.

So when the packet arrives.. it will be sourced from
Z2 ... which in theory, the peer did not know about...

This is why when parsing INIT/INIT-ACK's an implementation
must consider ALL addresses listed in both the INIT
and the INIT-ACK's .. even Z must do that incase a
collision case is happening where the A side restarted. It
needs to find out if A1 or A2 are already inside an association
or not.

So .. bottom line is all one needs to do for your case is
has Michael stated..

When the guy sends in the INIT .. it can be forwarded by
Mobile-IP... when it arrives at the real address send back
the INIT-ACK with a source address of the mobile address and
just list the "home" address inside the INIT-ACK. After
the assoc is up.. send a ASCONF that deletes the "home" address.

This is also how Anycast and SCTP will work well together too.
Since you can do the same scenario with an Anycast address ...

R


>  
> br
> /sal
> 
> Michael Tuexen <[e-mail]> wrote:
> Hi Sal,
> 
> you can just use the real address as the source address of the
> INIT-ACK and list the destination address of the INIT in the
> INIT-ACK.
> So the COOKIE-ECHO should go to the real address.
> 
> After the handshake you could delete the address.
> 
> Please note that the intention of ADDIP is not mobility,
> but allow for reconfiguration in long living associations
> without interrupting the service.
> 
> Best regards
> Michael
> 
> On Mar 1, 2005, at 14:50 Uhr, Salvatore Loreto wrote:
> 
> 
>>Hi Michael,
>> 
>>my scenario is this,
>>suppose I want start a session with a node belongto a Mobile IP 
>>network, and this node moved to a foreign network...
>>so now when the MN receives an INIT, I think insert in the INIT ACK 
>>also a ASCONF chunk with the real address (it has in the foreign 
>>network), should improve mobility delay.
>> 
>>br
>>Sal
>>
>>Michael Tuexen wrote:
>>Hi Sal,
>>
>>why not just use the correct addresses dring setup? If
>>one of the addresses is not valid anymore it can not be
>>used for DATA transfer, because it will not be verified.
>>
>>And the SCTP chunk authentication, which is now required
>>for ASCONF/ASCONF-ACK chunks needs the 4 way handshake
>>to establish a shared key. See
>>http://www.ietf.org/internet-drafts/draft-tuexen-sctp-auth-chunk-03.txt
>>
>>Best regards
>>Michael
>>
>>On Mar 1, 2005, at 9:20 Uhr, Salvatore Loreto wrote:
>>
>>
>>>Hi all,
>>> 
>>>I've a question about addip:
>>> 
>>>why is it impossible change an association address during the four 
>>
>>way
>>
>>>handshaking ?
>>> 
>>>br
>>>Sal
>>>
>>>[e-mail] wrote:
>>>A New Internet-Draft is available from the on-line Internet-Drafts
>>>directories.
>>>This draft is a work item of the Transport Area Working Group Working
>>>Group of the IETF.
>>>
>>>Title : Stream Control Transmission Protocol (SCTP) Dynamic Address
>>>Reconfiguration
>>>Author(s) : R. Stewart, et al.
>>>Filename : draft-ietf-tsvwg-addip-sctp-11.txt
>>>Pages : 35
>>>Date : 2005-2-22
>>>
>>>This document describes extensions to the Stream Control Transmission
>>>Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP
>>>address information on an existing association.
>>>
>>>A URL for this Internet-Draft is:
>>>
>>
>>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-11.txt
>>
>>>To remove yourself from the I-D Announcement list, send a message to
>>>[e-mail] with the word unsubscribe in the body 
>>
>>of
>>
>>>the message.
>>>You can also visit 
>>
>>https://www1.ietf.org/mailman/listinfo/I-D-announce
>>
>>>to change your subscription settings.
>>>
>>>
>>>Internet-Drafts are also available by anonymous FTP. Login with the
>>>username
>>>"anonymous" and a password of your e-mail address. After logging in,
>>>type "cd internet-drafts" and then
>>>"get draft-ietf-tsvwg-addip-sctp-11.txt".
>>>
>>>A list of Internet-Drafts directories can be found in
>>>http://www.ietf.org/shadow.html
>>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>
>>>Internet-Drafts can also be obtained by e-mail.
>>>
>>>Send a message to:
>>>[e-mail].
>>>In the body type:
>>>"FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-11.txt".
>>>
>>>NOTE: The mail server at ietf.org can return the document in
>>>MIME-encoded form by using the "mpack" utility. To use this
>>>feature, insert the command "ENCODING mime" before the "FILE"
>>>command. To decode the response(s), you will need "munpack" or
>>>a MIME-compliant mail reader. Different MIME-compliant mail readers
>>>exhibit different behavior, especially when dealing with
>>>"multipart" MIME messages (i.e. documents which have been split
>>>up into multiple messages), so check your local documentation on
>>>how to manipulate these messages.
>>>
>>>
>>>Below is the data which will enable a MIME compliant mail reader
>>>implementation to automatically retrieve the ASCII version of the
>>>Internet-Draft.
>>>_______________________________________________
>>>tsvwg mailing list
>>>[e-mail]
>>>https://www1.ietf.org/mailman/listinfo/tsvwg
>>>
>>>Nuovo Yahoo! Messenger E' molto più divertente: Audibles, Avatar,
>>>Webcam, Giochi, Rubrica… Scaricalo
>>>ora!_______________________________________________
>>>tsvwg mailing list
>>>[e-mail]
>>>https://www1.ietf.org/mailman/listinfo/tsvwg
>>
>>
>>_______________________________________________
>>tsvwg mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/tsvwg
>>
>>Nuovo Yahoo! Messenger E' molto più divertente: Audibles, Avatar, 
>>Webcam, Giochi, Rubrica… Scaricalo ora!
> 
> 
> 				
> ---------------------------------
> Nuovo Yahoo! Messenger E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora! 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> tsvwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tsvwg


-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

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