The Experts below are selected from a list of 4389 Experts worldwide ranked by ideXlab platform

Erwin P. Rathgeb - One of the best experts on this subject based on the ideXlab platform.

  • Network Address Translation for the Stream Control Transmission Protocol
    IEEE Network, 2008
    Co-Authors: Michael Tuxen, Irene Rungeler, Randall Stewart, Erwin P. Rathgeb
    Abstract:

    Network Address Translation is widely deployed in the Internet and supports the transmission control protocol and the user datagram protocol as transport layer protocols. Although part of the kernels of all recent Linux distributions, namely, the FreeBSD 7 and the Solaris 10 operating systems, the new Internet Engineering Task Force transport protocol - stream control transmission protocol - is not supported on most NAT middleboxes yet. This article discusses the deficiencies of using existing NAT methods for SCTP and describes a new SCTP-specific NAT concept. This concept is analyzed in detail for several important Network scenarios, including peer-to-peer, transport layer mobility, and multihoming.

Michael Tuxen - One of the best experts on this subject based on the ideXlab platform.

  • Stream Control Transmission Protocol (SCTP) Network Address Translation
    2013
    Co-Authors: Irene Ruengeler, Randall Stewart, Michael Tuxen
    Abstract:

    Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 Address, even when two hosts (behind the NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation or NAPT. To date, specialized code for SCTP has NOT yet been added to most NAT's so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes an SCTP specific variant of NAT which provides similar features of NAPT in the single point and multi-point traversal scenario.

  • Network Address Translation for the Stream Control Transmission Protocol
    IEEE Network, 2008
    Co-Authors: Michael Tuxen, Irene Rungeler, Randall Stewart, Erwin P. Rathgeb
    Abstract:

    Network Address Translation is widely deployed in the Internet and supports the transmission control protocol and the user datagram protocol as transport layer protocols. Although part of the kernels of all recent Linux distributions, namely, the FreeBSD 7 and the Solaris 10 operating systems, the new Internet Engineering Task Force transport protocol - stream control transmission protocol - is not supported on most NAT middleboxes yet. This article discusses the deficiencies of using existing NAT methods for SCTP and describes a new SCTP-specific NAT concept. This concept is analyzed in detail for several important Network scenarios, including peer-to-peer, transport layer mobility, and multihoming.

Randall Stewart - One of the best experts on this subject based on the ideXlab platform.

  • Stream Control Transmission Protocol (SCTP) Network Address Translation Support
    2020
    Co-Authors: Irene Ruengeler, Randall Stewart
    Abstract:

    The Stream Control Transmission Protocol (SCTP) provides a reliable communications channel between two end-hosts in many ways similar to the Transmission Control Protocol (TCP). With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet share a single IPv4 Address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation (NAPT). This document describes the protocol extensions required for the SCTP endpoints and the mechanisms for NAT devices necessary to provide similar features of NAPT in the single point and multi point traversal scenario. Finally, a YANG module for SCTP NAT is defined.

  • Stream Control Transmission Protocol (SCTP) Network Address Translation
    2013
    Co-Authors: Irene Ruengeler, Randall Stewart, Michael Tuxen
    Abstract:

    Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 Address, even when two hosts (behind the NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation or NAPT. To date, specialized code for SCTP has NOT yet been added to most NAT's so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes an SCTP specific variant of NAT which provides similar features of NAPT in the single point and multi-point traversal scenario.

  • Network Address Translation for the Stream Control Transmission Protocol
    IEEE Network, 2008
    Co-Authors: Michael Tuxen, Irene Rungeler, Randall Stewart, Erwin P. Rathgeb
    Abstract:

    Network Address Translation is widely deployed in the Internet and supports the transmission control protocol and the user datagram protocol as transport layer protocols. Although part of the kernels of all recent Linux distributions, namely, the FreeBSD 7 and the Solaris 10 operating systems, the new Internet Engineering Task Force transport protocol - stream control transmission protocol - is not supported on most NAT middleboxes yet. This article discusses the deficiencies of using existing NAT methods for SCTP and describes a new SCTP-specific NAT concept. This concept is analyzed in detail for several important Network scenarios, including peer-to-peer, transport layer mobility, and multihoming.

Irene Rungeler - One of the best experts on this subject based on the ideXlab platform.

  • Network Address Translation for the Stream Control Transmission Protocol
    IEEE Network, 2008
    Co-Authors: Michael Tuxen, Irene Rungeler, Randall Stewart, Erwin P. Rathgeb
    Abstract:

    Network Address Translation is widely deployed in the Internet and supports the transmission control protocol and the user datagram protocol as transport layer protocols. Although part of the kernels of all recent Linux distributions, namely, the FreeBSD 7 and the Solaris 10 operating systems, the new Internet Engineering Task Force transport protocol - stream control transmission protocol - is not supported on most NAT middleboxes yet. This article discusses the deficiencies of using existing NAT methods for SCTP and describes a new SCTP-specific NAT concept. This concept is analyzed in detail for several important Network scenarios, including peer-to-peer, transport layer mobility, and multihoming.

Grenville Armitage - One of the best experts on this subject based on the ideXlab platform.

  • issues with Network Address Translation for sctp
    ACM Special Interest Group on Data Communication, 2008
    Co-Authors: David Hayes, Grenville Armitage
    Abstract:

    A Stream Control Transmission Protocol (SCTP) capable Network Address Translation (NAT) device is necessary to support the wider deployment of the SCTP protocol. The key issues for an SCTP NAT are SCTP's control chunk multiplexing and multi-homing features. Control chunk multiplexing can expose an SCTP NAT to possible Denial of Service attacks. These can be mitigated through the use of chunk and parameter processing limits. Multiple and changing IP Addresses during an SCTP association, mean that SCTP NATs cannot operate in the way conventional UDP/TCP NATs operate. Tracking these multiple global IP Addresses can help in avoiding lookup table conflicts, however, it can also result in circumstances that can lead to NAT state inconsistencies. Our analysis shows that tracking global IP Addresses is not necessary in most expected practical installations. We use our FreeBSD SCTP NAT implementation, alias_sctp to examine the performance implications of tracking global IP Addresses. We find that typical memory usage doubles and that the processing requirements are significant for installations that experience high association arrival rates. In conclusion we provide practical recommendations for a secure stable SCTP NAT installation.