rfc3102.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,389 行 · 第 1/5 页

Network Working Group                                           Editors:
Request for Comments: 3102                                    M. Borella
Category: Experimental                                         CommWorks
                                                                   J. Lo
                                                    Candlestick Networks
                                                           Contributors:
                                                            D. Grabelsky
                                                               CommWorks
                                                           G. Montenegro
                                                        Sun Microsystems
                                                            October 2001


                      Realm Specific IP: Framework

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

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

IESG Note

   The IESG notes that the set of documents describing the RSIP
   technology imply significant host and gateway changes for a complete
   implementation.  In addition, the floating of port numbers can cause
   problems for some applications, preventing an RSIP-enabled host from
   interoperating transparently with existing applications in some cases
   (e.g., IPsec).  Finally, there may be significant operational
   complexities associated with using RSIP.  Some of these and other
   complications are outlined in section 6 of RFC 3102, as well as in
   the Appendices of RFC 3104.  Accordingly, the costs and benefits of
   using RSIP should be carefully weighed against other means of
   relieving address shortage.

Abstract

   This document examines the general framework of Realm Specific IP
   (RSIP).  RSIP is intended as a alternative to NAT in which the end-
   to-end integrity of packets is maintained.  We focus on
   implementation issues, deployment scenarios, and interaction with
   other layer-three protocols.




Borella, et al.               Experimental                      [Page 1]

RFC 3102                    RSIP: Framework                 October 2001


Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  2
   1.1. Document Scope  . . . . . . . . . . . . . . . . . . . . . .  4
   1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3. Specification of Requirements . . . . . . . . . . . . . . .  5
   2. Architecture  . . . . . . . . . . . . . . . . . . . . . . . .  6
   3. Requirements  . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.1. Host and Gateway Requirements . . . . . . . . . . . . . . .  7
   3.2. Processing of Demultiplexing Fields . . . . . . . . . . . .  8
   3.3. RSIP Protocol Requirements and Recommendations  . . . . . .  9
   3.4. Interaction with DNS  . . . . . . . . . . . . . . . . . . . 10
   3.5. Locating RSIP Gateways  . . . . . . . . . . . . . . . . . . 11
   3.6. Implementation Considerations . . . . . . . . . . . . . . . 11
   4. Deployment  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.1. Possible Deployment Scenarios . . . . . . . . . . . . . . . 12
   4.2. Cascaded RSIP and NAT . . . . . . . . . . . . . . . . . . . 14
   5. Interaction with Layer-Three Protocols  . . . . . . . . . . . 17
   5.1. IPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   5.2. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . 18
   5.3. Differentiated and Integrated Services  . . . . . . . . . . 18
   5.4. IP Multicast  . . . . . . . . . . . . . . . . . . . . . . . 21
   6. RSIP Complications  . . . . . . . . . . . . . . . . . . . . . 23
   6.1. Unnecessary TCP TIME_WAIT . . . . . . . . . . . . . . . . . 23
   6.2. ICMP State in RSIP Gateway  . . . . . . . . . . . . . . . . 23
   6.3. Fragmentation and IP Identification Field Collision . . . . 24
   6.4. Application Servers on RSAP-IP Hosts  . . . . . . . . . . . 24
   6.5. Determining Locality of Destinations from an RSIP Host. . . 25
   6.6. Implementing RSIP Host Deallocation . . . . . . . . . . . . 26
   6.7. Multi-Party Applications  . . . . . . . . . . . . . . . . . 26
   6.8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 27
   7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
   8. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 27
   9. References  . . . . . . . . . . . . . . . . . . . . . . . . . 28
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29
   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . 30

1.  Introduction

   Network Address Translation (NAT) has become a popular mechanism of
   enabling the separation of addressing spaces. A NAT router must
   examine and change the network layer, and possibly the transport
   layer, header of each packet crossing the addressing domains that the
   NAT router is connecting.  This causes the mechanism of NAT to
   violate the end-to-end nature of the Internet connectivity, and
   disrupts protocols requiring or enforcing end-to-end integrity of
   packets.




Borella, et al.               Experimental                      [Page 2]

RFC 3102                    RSIP: Framework                 October 2001


   While NAT does not require a host to be aware of its presence, it
   requires the presence of an application layer gateway (ALG) within
   the NAT router for each application that embeds addressing
   information within the packet payload.  For example, most NATs ship
   with an ALG for FTP, which transmits IP addresses and port numbers on
   its control channel.  RSIP (Realm Specific IP) provides an
   alternative to remedy these limitations.

   RSIP is based on the concept of granting a host from one addressing
   realm a presence in another addressing realm by allowing it to use
   resources (e.g., addresses and other routing parameters) from the
   second addressing realm.  An RSIP gateway replaces the NAT router,
   and RSIP-aware hosts on the private network are referred to as RSIP
   hosts.  RSIP requires ability of the RSIP gateway to grant such
   resources to RSIP hosts.  ALGs are not required on the RSIP gateway
   for communications between an RSIP host and a host in a different
   addressing realm.

   RSIP can be viewed as a "fix", of sorts, to NAT.  It may ameliorate
   some IP address shortage problems in some scenarios without some of
   the limitations of NAT.  However, it is not a long-term solution to
   the IP address shortage problem.  RSIP allows a degree of address
   realm transparency to be achieve between two differently-scoped, or
   completely different addressing realms.  This makes it a useful
   architecture for enabling end-to-end packet transparency between
   addressing realms.  RSIP is expected to be deployed on privately
   addresses IPv4 networks and used to grant access to publically
   addressed IPv4 networks.  However, in place of the private IPv4
   network, there may be an IPv6 network, or a non-IP network.  Thus,
   RSIP allows IP connectivity to a host with an IP stack and IP
   applications but no native IP access.  As such, RSIP can be used, in
   conjunction with DNS and tunneling, to bridge IPv4 and IPv6 networks,
   such that dual-stack hosts can communicate with local or remote IPv4
   or IPv6 hosts.

   It is important to note that, as it is defined here, RSIP does NOT
   require modification of applications.  All RSIP-related modifications
   to an RSIP host can occur at layers 3 and 4.  However, while RSIP
   does allow end-to-end packet transparency, it may not be transparent
   to all applications.  More details can be found in the section "RSIP
   complications", below.










Borella, et al.               Experimental                      [Page 3]

RFC 3102                    RSIP: Framework                 October 2001


1.1.  Document Scope

   This document provides a framework for RSIP by focusing on four
   particular areas:

      -  Requirements of an RSIP host and RSIP gateway.

      -  Likely initial deployment scenarios.

      -  Interaction with other layer-three protocols.

      -  Complications that RSIP may introduce.

   The interaction sections will be at an overview level.  Detailed
   modifications that would need to be made to RSIP and/or the
   interacting protocol are left for separate documents to discuss in
   detail.

   Beyond the scope of this document is discussion of RSIP in large,
   multiple-gateway networks, or in environments where RSIP state would
   need to be distributed and maintained across multiple redundant
   entities.

   Discussion of RSIP solutions that do not use some form of tunnel
   between the RSIP host and RSIP gateway are also not considered in
   this document.

   This document focuses on scenarios that allow privately-addressed
   IPv4 hosts or IPv6 hosts access to publically-addressed IPv4
   networks.

1.2.  Terminology

   Private Realm

      A routing realm that uses private IP addresses from the ranges
      (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) specified in
      [RFC1918], or addresses that are non-routable from the Internet.

   Public Realm

      A routing realm with globally unique network addresses.

   RSIP Host

      A host within an addressing realm that uses RSIP to acquire
      addressing parameters from another addressing realm via an RSIP
      gateway.



Borella, et al.               Experimental                      [Page 4]

RFC 3102                    RSIP: Framework                 October 2001


   RSIP Gateway

      A router or gateway situated on the boundary between two
      addressing realms that is assigned one or more IP addresses in at
      least one of the realms.  An RSIP gateway is responsible for
      parameter management and assignment from one realm to RSIP hosts
      in the other realm.  An RSIP gateway may act as a normal NAT
      router for hosts within the a realm that are not RSIP enabled.

   RSIP Client

      An application program that performs the client portion of the
      RSIP client/server protocol.  An RSIP client application MUST
      exist on all RSIP hosts, and MAY exist on RSIP gateways.

   RSIP Server

      An application program that performs the server portion of the
      RSIP client/server protocol.  An RSIP server application MUST
      exist on all RSIP gateways.

   RSA-IP: Realm Specific Address IP

      An RSIP method in which each RSIP host is allocated a unique IP
      address from the public realm.

   RSAP-IP: Realm Specific Address and Port IP

      An RSIP method in which each RSIP host is allocated an IP address
      (possibly shared with other RSIP hosts) and some number of per-
      address unique ports from the public realm.

   Demultiplexing Fields

      Any set of packet header or payload fields that an RSIP gateway
      uses to route an incoming packet to an RSIP host.

   All other terminology found in this document is consistent with that
   of [RFC2663].

1.3.  Specification of Requirements

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   documents are to be interpreted as described in [RFC2119].