Chronological Thread 

< Chronological >      < Thread >

---

Hi Ilknur,

I'm attaching the expired ID. Randy and I will update it and resubmit it soon. It will also cover
IPv6 adresses.

Please note that it does not cover ADDIP, but the same applies to ADDIP what is described for
the INIT/INIT-ACK.

I hope this makes things a bit clearer.

Best regards
Michael



Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc.
Expires: November 15, 2002 M. Tuexen
Siemens AG
May 17, 2002


Stream Control Transmission Protocol (SCTP) IPv4 Address Scoping
draft-stewart-tsvwg-sctpipv4-00.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 15, 2002.

Copyright Notice

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract

Stream Control Transmission Protocol RFC2960 [5] provides transparent
multi-homing to its upper layer users. This multi-homing is
accomplished through the passing of address parameters in the initial
setup message used by SCTP. In an IPv4 network addresses SHOULD NOT
be passed without consideration of their routeablility. This
document defines considerations and enumerates general rules that an
SCTP endpoint MUST use in formulating both the INIT and INIT-ACK
chunks when including IPv4 addresses.





Stewart & Tuexen Expires November 15, 2002 [Page 1]

Internet-Draft SCTP IPv4 Address Scoping May 2002


Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IPv4 address scoping . . . . . . . . . . . . . . . . . . . . . 5
3.1 Classification of IPV4 addresses . . . . . . . . . . . . . . . 5
3.2 Black-hole scenario . . . . . . . . . . . . . . . . . . . . . 5
3.3 Address handling for INIT chunks . . . . . . . . . . . . . . . 5
3.4 Address handling for INIT-ACK chunks . . . . . . . . . . . . . 6
4. Security considerations . . . . . . . . . . . . . . . . . . . 7
References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9






































Stewart & Tuexen Expires November 15, 2002 [Page 2]

Internet-Draft SCTP IPv4 Address Scoping May 2002


1. Introduction

Stream Control Transmission Protocol RFC2960 [5] provides transparent
multi-homing to its upper layer users. This multi-homing is
accomplished through the passing of address parameters in the initial
setup message used by SCTP. In an IPv4 network addresses SHOULD NOT
be passed without consideration of their routeablility. This
document defines considerations and enumerates general rules that an
SCTP endpoint MUST use in formulating both the INIT and INIT-ACK
chunks when including IPv4 addresses.

The emphasis in the rules laid out in this document are to prevent an
SCTP endpoint from listing an IPv4 address that is not routeable to a
peer endpoint. This will minimize black-hole conditions that may
cause the unexpected failure of SCTP associations.




































Stewart & Tuexen Expires November 15, 2002 [Page 3]

Internet-Draft SCTP IPv4 Address Scoping May 2002


2. Conventions

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
RFC2119 [4].













































Stewart & Tuexen Expires November 15, 2002 [Page 4]

Internet-Draft SCTP IPv4 Address Scoping May 2002


3. IPv4 address scoping

3.1 Classification of IPV4 addresses

Several blocks of IP-addresses have been assigned by IANA for special
use. See IANA-SPECIAL-IPV4 [1] for further details.

In this document the IPv4 addresses are divided into several
different levels:

Level 0: Addresses unusable with SCTP: 0.0.0.0/8, 224.0.0.0/4,
198.18.0.0/24, 192.88.99.0/24.

Level 1: Loopback addresses: 127.0.0.0/8.

Level 2: Link-local addresses: 169.254.0.0/16.

Level 3: Private addresses: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/
16.

Level 4: Global addresses.

Addresses of Level 0 MUST not be used

o as a source address of a SCTP packet.

o as a destination address of a SCTP packet.

o within an address parameter of an INIT, INIT-ACK chunk.


3.2 Black-hole scenario

A black-hole condition is where some other host is using the same
address. In a IPv4 network this COULD happen if an INIT was sent to
a global address that listed private addresses. If the peer also has
a separate private based addressing it MAY send a heartbeat to an
internal peer using the address listed. This causes the internal
peer to send an ABORT thus destroying the association.

The rules given in the next two sections for address handling will
minimize the risk of having a black-hole condition.

3.3 Address handling for INIT chunks

When the ULP requests establishment of an SCTP association to a IPv4
destination address, the following considerations apply:




Stewart & Tuexen Expires November 15, 2002 [Page 5]

Internet-Draft SCTP IPv4 Address Scoping May 2002


o Let L be the level of the requested destination address.
Therefore L > 0 holds.

o The sender of the INIT chunk SHOULD include all of its addresses
with level greater than or equal to L in the outgoing INIT chunk.

o The sender of the INIT chunk SHOULD NOT include all of its
addresses with level smaller than L in the outgoing INIT chunk.

Note that by listing both private and global addresses to a peer that
does NOT have any global address the peer may find the senders global
address unreachable. This is not a problem however since it would
NOT cause a black-hole condition.

3.4 Address handling for INIT-ACK chunks

The receiver of an INIT will identify the relevant address level by
examining the source address of the SCTP packet. In choosing
addresses to place in the INIT-ACK the following considerations
apply:

o Let L be the level of the received source address of the INIT
chunk. Therefore L > 0 holds.

o The sender of the INIT-ACK chunk SHOULD include all of its
addresses with level greater than or equal to L in the outgoing
INIT-ACK chunk.

o The sender of the INIT-ACK chunk SHOULD NOT include all of its
addresses with level smaller than L in the outgoing INIT-ACK
chunk.

Note that it is possible that a sender of an INIT incorrectly places
addresses within its INIT. To protect against this the receiver of
the INIT SHOULD examine carefully each address. If the level of an
address listed is less than the level of the received source address,
the address SHOULD be discarded and not put into the cookie
parameter.













Stewart & Tuexen Expires November 15, 2002 [Page 6]

Internet-Draft SCTP IPv4 Address Scoping May 2002


4. Security considerations

This document does not add any security risks other than those
already found in RFC2960 [5]















































Stewart & Tuexen Expires November 15, 2002 [Page 7]

Internet-Draft SCTP IPv4 Address Scoping May 2002


References

[1] IANA, I., "Special-Use IPv4 Addresses", draft-iana-special-ipv4-
03 (work in progress), April 2002.

[2] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E.
Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.

[3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.

[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.


Authors' Addresses

Randall R. Stewart
Cisco Systems, Inc.
8725 West Higgins Road
Suite 300
Chicago, IL 60631
USA

Phone: +1-815-477-2127
EMail:
rrs AT cisco.com


Michael Tuexen
Siemens AG
ICN WN CC SE 7
D-81359 Munich
Germany

Phone: +49 89 722 47210
EMail:
Michael.Tuexen AT icn.siemens.de










Stewart & Tuexen Expires November 15, 2002 [Page 8]

Internet-Draft SCTP IPv4 Address Scoping May 2002


Full Copyright Statement

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.



















Stewart & Tuexen Expires November 15, 2002 [Page 9]



On May 1, 2005, at 9:29 PM, Ilknur Aydin wrote:

Hi Michael,

the routing socket should become readable, but the address should not be incorporated into
the association sue to the address scoping, which is going on.

sorry, but I could not understand your reply. Could you elaborate more please. You are saying that since the assoc. starts with local addresses, the private ip address is not added into the association ?


Thanks,
ilknur

On May 1, 2005, at 7:09 PM, Ilknur Aydin wrote:

Hello Andreas,
I am working with sctplib1.3.1 on the add/delete ip feature. Previously, I had read the source files on how add/delete ip feature is triggered. As far as I see, a routing socket is opened by sctplib and whenever there is change (add/delete) in the routing table, sending of an asconf add/delete ip chunk is triggered.
I had run echo_server and terminal programs and by using ifconfig, I was be able to observe paths added/deleted into the association. However, these were not consistent. For I while, I worked on some other things, and later needed to go back and check add/delete ip feature again, and now, I can not observe the feature at all :(.
The configuration, I use is like in Figure-1 (of the attached .pdf file).
I try the steps 1-5 below.
---------------------------------------
1- Initially, eth0 is not active, there is only loop back address in the routing table (see below).
[root@localhost programs]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
[root@localhost programs]# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:585875 errors:0 dropped:0 overruns:0 frame:0
TX packets:585875 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:45330936 (43.2 Mb) TX bytes:45330936 (43.2 Mb)
2- then, I ran echo_server and terminal on the loop back address as below, and communication is established between them.
./echo_server -V -s 127.0.0.1
1 : Communication up (10 In-Streams, 10 Out-Streams, 1 Paths)
1 : Network status change notification: path 1 status is ACTIVE STATE (0)
./terminal -V -d 127.0.0.1 -s 127.0.0.1
1 : Communication up (1 paths, 10 In-Streams, 10 Out-Streams)
1 : Network status change notification: path 1 state is ACTIVE STATE (0)
3- then I activated eth0 with the ifconfig command below.
[root@localhost programs]# ifconfig eth0 up
4- the result is that eth0 is activated with the private IP address (192.168.0.158).
[root@localhost programs]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0F:1F:10:8B:96
inet addr:192.168.0.158 Bcast:192.168.0.255 Mask: 255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:1873 errors:0 dropped:0 overruns:0 frame:0
TX packets:189 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:474075 (462.9 Kb) TX bytes:21144 (20.6 Kb)
Interrupt:11 Base address:0xe000 Memory:faffe000-fafff080
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:586221 errors:0 dropped:0 overruns:0 frame:0
TX packets:586221 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:45357419 (43.2 Mb) TX bytes:45357419 (43.2 Mb)
[root@localhost programs]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
5- However , though the routing table changes, I do not see "Network status change notification: " printed in neither echo_server nor "terminal" windows. That is, it is as if sctplib is not informed about the changes in the routing table.
Do you think that somehow the configuration in Figure-1 is not proper to observe add/delete ip feature ??
Now, I am trying to introduce a wireless interface to the laptop and try the set up like in Figure-2. Later, I will try to turn on and off the wireless interface and try to observe the add/delete ip. Do you think this set up would help observing add/delete ip feature ? Can you foresee any problems with this set up?
What kind configuration you had use while testing this feature ??
Thanks,
ilknur
<q.to.andreas.pdf>

---

• [SCTP-Discussion] sctplib1.3.1, add/delete ip, Ilknur Aydin, 05/01/2005
  • Re: [SCTP-Discussion] sctplib1.3.1, add/delete ip, Michael Tuexen, 05/01/2005
    • Re: [SCTP-Discussion] sctplib1.3.1, add/delete ip, Ilknur Aydin, 05/01/2005
      • Re: [SCTP-Discussion] sctplib1.3.1, add/delete ip, Michael Tuexen, 05/01/2005
        • Re: [SCTP-Discussion] sctplib1.3.1, add/delete ip, Ilknur Aydin, 05/01/2005
          • Re: [SCTP-Discussion] sctplib1.3.1, add/delete ip, Michael Tuexen, 05/02/2005
          • Message not available
            • Re: [SCTP-Discussion] sctplib1.3.1, add/delete ip, Ilknur Aydin, 05/04/2005

---

Archive powered by MHonArc 2.6.19+.