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

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.

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.

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.

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

  • Definitions of Managed Objects for Network Address Translators (NAT)
    2005
    Co-Authors: P Srisuresh, Rajiv Raghunarayan, R. Rohit, Nalinaksh Pai, Cliff Wang
    Abstract:

    This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for configuration as well as monitoring of a device capable of NAT function. [STANDARDS-TRACK]

  • Definitions of Managed Objects for Network Address Translators (NAT) Status of This Memo
    2005
    Co-Authors: R. Rohit, P Srisuresh, Nalinaksh Pai, Cliff Wang
    Abstract:

    This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for configuration as well as monitoring of a device capable of NAT function.

  • traditional ip Network Address translator traditional nat
    RFC3022, 2001
    Co-Authors: P Srisuresh, K Egevang
    Abstract:

    Basic Network Address Translation or Basic NAT is a method by which IP Addresses are mapped from one group to another, transparent to end users. Network Address Port Translation, or NAPT is a method by which many Network Addresses and their TCP/UDP (Transmission Control Protocol/User Datagram Protocol) ports are translated into a single Network Address and its TCP/UDP ports. Together, these two operations, referred to as traditional NAT, provide a mechanism to connect a realm with private Addresses to an external realm with globally unique registered Addresses.

  • protocol complications with the ip Network Address translator
    RFC, 2001
    Co-Authors: M Holdrege, P Srisuresh
    Abstract:

    Many internet applications can be adversely affected when end nodes are not in the same Address realm and seek the assistance of an IP Network Address Translator (NAT) enroute to bridge the realms. The NAT device alone cannot provide the necessary application/protocol transparency in all cases and seeks the assistance of Application Level Gateways (ALGs) where possible, to provide transparency. The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. It is not possible to capture all applications that break with NAT in a single document. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. We hope the coverage provides sufficient clues for applications not covered.

  • Network Address translation protocol translation nat pt
    RFC 2766, 2000
    Co-Authors: George Tsirtsis, P Srisuresh
    Abstract:

    This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified in [TRANS]. This solution attempts to provide transparent routing, as defined in [NAT-TERM], to end-nodes in V6 realm trying to communicate with end-nodes in V4 realm and vice versa. This is achieved using a combination of Network Address Translation and Protocol Translation. The scheme described does not mandate dual-stacks (i.e., IPv4 as well as V6 protocol support) or special purpose routing requirements (such as requiring tunneling support) on end nodes. This scheme is based on a combination of Address translation theme as described in [NAT-TERM] and V6/V4 protocol translation theme as described in [SIIT].

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.

  • Inferring the extent of Network Address port translation at public/private internet boundaries
    2002
    Co-Authors: Grenville Armitage
    Abstract:

    This technical report describes a relatively simple method for inferring the percentage of public/private internet boundaries that utilize Network Address port translation (NAPT, often colloquially referred to as NAT). Estimates were obtained from the IP Address/port pairs seen in the server logs of three well-used, online game servers between May 2001 and June 2002. The report concludes that NAPT may be in use at approximately 17 to 25% of public/private internet access boundaries in the online gaming community. Estimates of NAT deployment can help provide context for discussions about the need for IPv6 and other techqniues for scaling the Internet. Keywords-Internet, Network Address Translation, NAT, NAPT, IP Address, UDP Port, Quake III, fingerprint, inference, measurement