Browse Prior Art Database

IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation (RFC3424)

IP.com Disclosure Number: IPCOM000010298D
Original Publication Date: 2002-Nov-01
Included in the Prior Art Database: 2002-Nov-19
Document File: 10 page(s) / 18K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

L. Daigle: AUTHOR [+3]

Abstract

As a result of the nature of Network Address Translation (NAT) Middleboxes, 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 text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 15% of the total text.

Network Working Group                                     L. Daigle, Ed.

Request for Comments: 3424                   Internet Architecture Board

Category: Informational                                              IAB

                                                           November 2002

     IAB Considerations for UNilateral Self-Address Fixing (UNSAF)

                   Across Network Address Translation

Status of this Memo

   This memo provides information for the Internet community.  It does

   not specify an Internet standard of any kind.  Distribution of this

   memo is unlimited.

Copyright Notice

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

Abstract

   As a result of the nature of Network Address Translation (NAT)

   Middleboxes, 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.

1. Introduction

   As a result of the nature of Network Address (and port) Translation

   (NAT) Middleboxes, 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 - the address translation is locked within the NAT box.  For

   some purposes, endpoints need to know the addresses (and/or ports) by

   which they are known to their peers.  There are two cases: 1) when

   the client initiates communication, starting the communication has

   the side effect of creating an address binding in the NAT device and

Daigle & IAB                 Informational                      [Page 1]

RFC 3424        IAB Considerations for UNSAP Across NAT    November 2002

   allocating an address in the realm that is external to the NAT box;

   and 2) a server will be accepting connections from outside, but

   because it does not initiate communication, no NAT binding is

   created.  In such cases, a mechanism is needed to fix such a binding

   before communication can take place.

   "UNilateral Self-Address Fixing (...