Internet Drafts and RFCs: Architecture

We recommend you make yourself familiar with how this archive operates before you start using it.

rfc1627 rfc2993 rfc3235 draft-moore-nat-tolerance-recommendations draft-iab-unsaf-considerations

rfc1627.txt	Network 10 Considered Harmful (Some Practices Shouldn't be Codified)
Author(s)	E. Lear, E. Fair, D. Crocker, T. Kessler
Organization	ietf
State	informational
Size	18823 bytes
obsoleted by	rfc1918.txt

rfc2993.txt	Architectural Implications of NAT
Author(s)	T. Hain
Organization	ietf
State	informational
Size	74136 bytes
Abstract	In light of the growing interest in, and deployment of network address translation (NAT) RFC-1631, this paper will discuss some of the architectural implications and guidelines for implementations. It is assumed the reader is familiar with the address translation concepts presented in RFC-1631.

rfc3235.txt	Network Address Translator (NAT)-Friendly Application Design Guidelines
Author(s)	D. Senie
Organization	ietf
State	informational
Size	29588 bytes
Abstract	This document discusses those things that application designers might wish to consider when designing new protocols. While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation).

draft-moore-nat-tolerance-recommendations-01.txt

wdiff comparison with previous version

draft-iab-unsaf-considerations-02.txt IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation

Author(s) L. Daigle

Organization ietf

State unknown

Date 2002-07-02

Size 19052 bytes

Abstract As a result of the nature of network address translation middleboxes (NATs), communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-Address Fixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint -- e.g., to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems, and the specific issues to be carefully evaluated before creating an UNSAF proposal.

1998-2002, maintained by Jiri Kuthan.
Last Update: May 14, 2002

draft-iab-unsaf-considerations-02.txt	IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation
Author(s)	L. Daigle
Organization	ietf
State	unknown
Date	2002-07-02
Size	19052 bytes
Abstract	As a result of the nature of network address translation middleboxes (NATs), communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-Address Fixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint -- e.g., to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems, and the specific issues to be carefully evaluated before creating an UNSAF proposal.