RFC 3102

Realm Specific IP: Framework

📅 published October 2001, from ietf

RFC 3102 🎀 Realm Specific IP: Framework (Part 1 of 7)

Okay bestie, this is the RSIP framework doc, and the vibe is "here's the big picture before we get into the messy details" 🦋 It's an Experimental spec from October 2001, so it's not an Internet standard. It's more like a "try this and tell us what you think" situation 💅

The editors are M. Borella (CommWorks) and J. Lo (Candlestick Networks). The contributors are D. Grabelsky (CommWorks) and G. Montenegro (Sun Microsystems). The title block lists nothing under Obsoletes or Updates, so this doc isn't replacing or updating any earlier RFC 🌸

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 (C) The Internet Society (2001). All Rights Reserved.

IESG Note 🚨

Okay this one is important, so read it carefully 👀 The IESG says the whole set of RSIP documents implies significant host and gateway changes for a complete implementation. 😭 Port number floating can also cause problems for some applications, so an RSIP-enabled host might not work transparently with existing apps in some cases, like IPsec. And there may be big operational complexities too. Some of these complications are outlined in section 6 of RFC 3102, and more are in the Appendices of RFC 3104. So the costs and benefits of using RSIP should be weighed carefully against other ways of dealing with address shortage. Not a casual decision, babe 💀

Abstract 🦋

This document looks at the general framework of Realm Specific IP (RSIP). RSIP is meant to be an alternative to NAT where the end-to-end integrity of packets is kept intact. The focus is on implementation issues, deployment scenarios, and how RSIP interacts with other layer-three protocols 🧚

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 🌈

Okay so NAT (Network Address Translation) is super popular for splitting up addressing spaces 💅 The catch is that a NAT router has to look at and change the network layer header, and maybe the transport layer header, of every packet crossing between the addressing domains it connects. That's what breaks the end-to-end nature of Internet connectivity, and it messes with any protocol that needs or enforces end-to-end packet integrity. Not ideal, bestie 😩

NAT doesn't require a host to know it's there, but the NAT router needs an application layer gateway (ALG) for each application that puts addressing info inside the packet payload. For example, most NATs ship with an ALG for FTP, since FTP sends IP addresses and port numbers over its control channel. RSIP (Realm Specific IP) is the alternative that's supposed to fix these limitations 🦋

RSIP is built on the idea of giving a host from one addressing realm a presence in another realm, by letting it use resources (like addresses and other routing parameters) from that second realm. An RSIP gateway takes the place of the NAT router, and RSIP-aware hosts on the private network are called RSIP hosts. RSIP needs the RSIP gateway to be able to hand out those resources to RSIP hosts. ALGs are not needed on the RSIP gateway for communication between an RSIP host and a host in a different addressing realm, which is a huge win 🎀

Honest take: RSIP is kind of a "fix" for NAT. It might ease some IP address shortage problems in some scenarios, without some of the limitations NAT has. But it is not a long-term solution to IP address shortage 😬 RSIP can also give a degree of address realm transparency between two differently-scoped addressing realms, or two totally different ones. That makes it a useful architecture for end-to-end packet transparency across realms ✨ RSIP is expected to run on private IPv4 networks and be used to get access to public IPv4 networks. The private IPv4 network could also be an IPv6 network or even a non-IP network. So RSIP can give IP connectivity to a host that has an IP stack and IP applications but no native IP access. Combined with DNS and tunneling, RSIP can bridge IPv4 and IPv6 networks, so dual-stack hosts can talk to local or remote IPv4 or IPv6 hosts 🧚

Important note: as defined here, RSIP does not require changes to applications. All RSIP-related changes to an RSIP host can happen at layers 3 and 4. Still, RSIP allows end-to-end packet transparency but might not be transparent to every application. Check out the section "RSIP complications", below, for the details 👀

1.1. Document Scope 🔍

This document gives a framework for RSIP by focusing on four 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 stay at an overview level. Detailed changes that would need to be made to RSIP and/or the interacting protocol are left for separate documents to dig into 💖

Also out of scope: RSIP in large, multiple-gateway networks, and environments where RSIP state would have to be spread across and maintained by multiple redundant entities. RSIP solutions that don't use some kind of tunnel between the RSIP host and RSIP gateway aren't considered here either 🙈

This document focuses on scenarios where privately-addressed IPv4 hosts or IPv6 hosts get access to publicly-addressed IPv4 networks 🌸

1.2. Terminology 📚

Here's the vocab you need, babe 💜

  • Private Realm: A routing realm that uses private IP addresses from the ranges 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 (as specified in [RFC1918]), or addresses that can't be routed from the Internet.
  • Public Realm: A routing realm with globally unique network addresses.
  • RSIP Host: A host inside an addressing realm that uses RSIP to get addressing parameters from another addressing realm through an RSIP gateway.
  • RSIP Gateway: A router or gateway on the boundary between two addressing realms that has one or more IP addresses in at least one of those realms. The RSIP gateway handles 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 in its realm that aren't RSIP enabled 🎀
  • RSIP Client: An application program that performs the client side 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 side 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 where each RSIP host is allocated a unique IP address from the public realm.
  • RSAP-IP: Realm Specific Address and Port IP: An RSIP method where each RSIP host is allocated an IP address (which may be 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 in this document is consistent with [RFC2663] 🫶

1.3. Specification of Requirements ⭐

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those capital words are the official requirement language, so pay attention to them! 💅

That's the setup done, bestie! 🌈 Part 2 is where we get into the Architecture and the Requirements, so stay tuned 🦋

2. Architecture ✨

okay so picture this 🎀 there are a bunch of hosts living in one addressing realm, and they connect to another addressing realm through an RSIP gateway. It looks like this:

         RSIP Host             RSIP Gateway                    Host

            Xa                    Na   Nb                       Yb
         [X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y]
                  (  Network   )            (  Network   )

Hosts X and Y belong to different addressing realms, A and B. N is the RSIP gateway, and it's allowed to do NAT stuff too 💅. N has two interfaces, Na on address space A and Nb on address space B. N might have a pool of addresses in address space B that it can assign to or lend to X and other hosts in address space A 🦋. Those addresses aren't drawn in the diagram, but you can call them Nb1, Nb2, Nb3, and so on.

Realistically, the hosts in address space A are probably using private addresses, and the RSIP gateway is multi-homed. That means it has one or more private addresses from address space A, plus its public addresses from address space B 🌸. So we usually call the realm where the RSIP host lives "private," and the realm the RSIP host borrows addressing parameters from "public." But honestly, both realms could be public or both could be private. The labels are just for convenience. Address space A could even be an IPv6 realm or a non-IP address space, no cap 🧚

Now here's the main event. Host X wants to start an end-to-end connection to a network entity Y that sits in address space B. First, X negotiates and gets assigned resources (like addresses and other routing parameters from address space B) from the RSIP gateway 💖. Once those parameters are assigned, the RSIP gateway creates a mapping called a "bind," which ties X's addressing information to the assigned resources. That bind is what lets the gateway correctly demultiplex and forward inbound traffic that Y sends to X ✨. If the gateway allows it, X can make multiple binds on the same RSIP gateway, or spread them across several RSIP gateways. A lease time SHOULD be associated with each bind.

Next, RSIP hosts use the public parameters the gateway assigned to tunnel their data packets across address space A to the RSIP gateway 🫶. The gateway is the endpoint of those tunnels. It strips off the outer headers and routes the inner packets onto the public realm. Like we said earlier, the gateway keeps a mapping of the assigned public parameters as demultiplexing fields, so it can uniquely map them to each RSIP host's private addresses 🔥. When a packet from the public realm shows up and matches a given set of demultiplexing fields, the gateway tunnels it to the right RSIP host. So for outbound packets from X to Y, once X has been assigned Nb, the tunnel headers look like this:

            +---------+---------+---------+
            | X -> Na | Nb -> Y | payload |
            +---------+---------+---------+

There are two basic flavors of RSIP, RSA-IP and RSAP-IP 👑. RSIP hosts and gateways MAY support RSA-IP, RSAP-IP, or both.

With RSA-IP, the RSIP gateway keeps a pool of IP addresses that hosts can lease 🍓. When a host asks, the gateway hands it an IP address. Once an address belongs to a particular host, only that host may use it until it's returned to the pool. Hosts MAY NOT use addresses that haven't been specifically assigned to them 🙈. A host can use any TCP/UDP port along with its assigned address. Hosts can also run gateway applications on any port, and those apps will be reachable from the public network without any help from the RSIP gateway ✨. A host MAY lease more than one address, from the same gateway or different RSIP gateways. The demultiplexing fields of an RSA-IP session MUST include the IP address leased to the host.

With RSAP-IP, the gateway keeps a pool of IP addresses plus pools of port numbers for each address 🌈. RSIP hosts lease an IP address and one or more ports to go with it. Once an address/port tuple is allocated to a particular host, only that host may use that tuple until it goes back to the pool(s) 💜. Hosts MAY NOT use address/port combinations that haven't been specifically assigned to them. Hosts can run gateway applications bound to an allocated tuple, but those apps won't be available to the public network unless the RSIP gateway has agreed to route all traffic destined for the tuple to the host 😭. A host MAY lease more than one tuple, from the same gateway or different RSIP gateways. The demultiplexing fields of an RSAP-IP session MUST include the tuple(s) leased to the host.

3. Requirements 🎀

3.1. Host and Gateway Requirements

Let's talk about what RSIP hosts need to do. An RSIP host MUST be able to maintain one or more virtual interfaces for the IP address(es) it leases from an RSIP gateway 💅. It MUST also support tunneling and be able to act as an endpoint for one or more tunnels to RSIP gateways. An RSIP host MUST NOT respond to ARPs for a public realm address that it leases 🙈.

If an RSIP host supports RSAP-IP, it MUST be able to maintain a set of one or more ports assigned by an RSIP gateway, and it chooses its ephemeral source ports from that set 🦋. If the host's pool has no free ports left and the host needs to open a new communication session with a public host, it MUST be able to dynamically request one or more additional ports through its RSIP mechanism ✨.

An RSIP gateway is a multi-homed host that routes packets between two or more realms 👑. Often, it's a boundary router between two or more administrative domains. It MUST also support tunneling and be able to act as an endpoint for tunnels to RSIP hosts. The RSIP gateway MAY be a policy enforcement point, which may mean it also has to do firewall and packet filtering duties on top of RSIP 🧚. The RSIP gateway MUST reassemble all incoming packet fragments from the public network so it can route and tunnel them to the proper host. Since reassembly is needed for this, an RSIP gateway MUST timeout fragments that are never fully reassembled ⏳.

An RSIP gateway MAY include NAT functionality, so hosts on the private network that aren't RSIP-enabled can still talk to the public network 🌸. An RSIP gateway MUST manage all resources assigned to RSIP hosts. That management MAY be done according to local policy 💖.

3.2. Processing of Demultiplexing Fields

Every active RSIP host needs its own unique set of demultiplexing fields, so the RSIP gateway can route incoming packets to the right place 🫶. Depending on the type of mapping the gateway uses, demultiplexing fields can be one or more of the following:

  • destination IP address
  • IP protocol
  • destination TCP or UDP port
  • IPSEC SPI present in ESP or AH header (see [RFC3104])
  • others

Note that these fields can be augmented with the source IP address and source TCP or UDP port 💜.

Demultiplexing incoming traffic can be done with a decision tree 🌈. The process starts by examining the IP header of the incoming packet, then moves on to the subsequent headers and then the payload.

  • If a public IP address is assigned to each host, each RSIP host gets its own unique public IP address mapping ✨.
  • If the same IP address is used for more than one RSIP host, then the subsequent headers must have at least one field that gets a unique value per host, so it can work as a demultiplexing field. The IP protocol field SHOULD be used to figure out which fields in the subsequent headers these demultiplexing fields ought to be 🔥.
  • If the subsequent header is TCP or UDP, the destination port number can be used. However, if the TCP/UDP port number is the same for more than one RSIP host, the payload section of the packet must contain a demultiplexing field that is guaranteed to be different for each RSIP host. Typically this means the RSIP host and gateway have to negotiate those fields, so the RSIP gateway can guarantee that the fields are unique per host 😭.
  • If the subsequent header is anything other than TCP or UDP, there must be other fields within the IP payload that can be used as demultiplexing fields. In other words, those fields must be settable so that they're guaranteed to be unique per host. Typically this means the RSIP host and gateway negotiate those fields, so the RSIP gateway can guarantee uniqueness per host 🦋.

It's desirable for all demultiplexing fields to sit in well-known fixed locations, so an RSIP gateway can mask out and examine the right fields on incoming packets 🧚. Demultiplexing fields that are encrypted MUST NOT be used for routing 🙈.

3.3. RSIP Protocol Requirements and Recommendations

RSIP gateways and hosts MUST be able to negotiate IP addresses when using RSA-IP, IP address/port tuples when using RSAP-IP, and possibly other demultiplexing fields for use in other modes 💖.

In this section we go over the requirements and implementation issues of an RSIP negotiation protocol 🎀.

For each required demultiplexing field, an RSIP protocol MUST, at the very least, allow for:

  • RSIP hosts to request assignments of demultiplexing fields
  • RSIP gateways to assign demultiplexing fields with an associated lease time
  • RSIP gateways to reclaim assigned demultiplexing fields

Also, it's desirable, though not mandatory, for an RSIP protocol to negotiate an RSIP method (RSA-IP or RSAP-IP) and the type of tunnel to be used across the private network 🌸. The protocol SHOULD be extensible and facilitate vendor-specific extensions ✨.

If an RSIP negotiation protocol is implemented at the application layer, a choice of transport protocol MUST be made. RSIP hosts and gateways may communicate via TCP or UDP. TCP support is required in all RSIP gateways, while UDP support is optional. RSIP hosts may support TCP, UDP, or both. However, once an RSIP host and gateway have started communicating using either TCP or UDP, they MAY NOT switch to the other transport protocol 😭. For the RSIP implementations and deployments considered in this document, TCP is the recommended transport protocol, because TCP is known to be robust across a wide range of physical media types and traffic loads 💅.

It is recommended that all communication between an RSIP host and gateway be authenticated 🔥. Authentication, in the form of a message hash appended to the end of each RSIP protocol packet, can serve to authenticate the RSIP host and gateway to one another, provide message integrity, and (with an anti-replay counter) avoid replay attacks 🛡️. For authentication to be supported, each RSIP host and the RSIP gateway MUST either share a secret key (distributed, for example, by Kerberos) or have a private/public key pair 👑. In the latter case, an entity's public key can be computed over each message, and a hash function can be applied to the result to form the message hash 🌈.

3.4. Interaction with DNS ✨

Okay so an RSIP-enabled network has three uses for DNS 🎀: (1) public DNS services to map its static public IP addresses (i.e., the public address of the RSIP gateway) and for lookups of public hosts, (2) private DNS services for use only on the private network, and (3) dynamic DNS services for RSIP hosts.

With respect to (1), public DNS information MUST be propagated onto the private network. 🌸 With respect to (2), private DNS information MUST NOT be propagated into the public network. 🙅‍♀️

With respect to (3), an RSIP-enabled network MAY allow for RSIP hosts with FQDNs to have their A and PTR records updated in the public DNS. 💖 These updates are based on address assignment facilitated by RSIP, and should be performed in a fashion similar to DHCP updates to dynamic DNS [DHCP-DNS]. In particular, RSIP hosts should be allowed to update their A records but not PTR records, while RSIP gateways can update both. 🦋 In order for the RSIP gateway to update DNS records on behalf of an RSIP host, the host must provide the gateway with its FQDN. 🫶

Note that when using RSA-IP, the interaction with DNS is completely analogous to that of DHCP because the RSIP host "owns" an IP address for a period of time. ⭐ In the case of RSAP-IP, the claim that an RSIP host has to an address is only with respect to the port(s) that it has leased along with an address. 🧚 Thus, two or more RSIP hosts' FQDNs may map to the same IP address. 😭 However, a public host may expect that all of the applications running at a particular address are owned by the same logical host, which would not be the case. 💀 It is recommended that RSAP-IP and dynamic DNS be integrated with some caution, if at all. 🙈

3.5. Locating RSIP Gateways

When an RSIP host initializes, it requires (among other things) two critical pieces of information. 👑 One is a local (private) IP address to use as its own, and the other is the private IP address of an RSIP gateway. This information can be statically configured or dynamically assigned. ✨

In the dynamic case, the host's private address is typically supplied by DHCP. 🍓 A DHCP option could provide the IP address of an RSIP gateway in DHCPOFFER messages. Thus, the host's startup procedure would be as follows: (1) perform DHCP, (2) if an RSIP gateway option is present in the DHCPOFFER, record the IP address therein as the RSIP gateway. 💅

Alternatively, the RSIP gateway can be discovered via SLP (Service Location Protocol) as specified in [SLP-RSIP]. 🌈 The SLP template defined allows for RSIP service provisioning and load balancing. ⚖️

3.6. Implementation Considerations

RSIP can be accomplished by any one of a wide range of implementation schemes. 🦋 For example, it can be built into an existing configuration protocol such as DHCP or SOCKS, or it can exist as a separate protocol. This section discusses implementation issues of RSIP in general, regardless of how the RSIP mechanism is implemented. 💜

Note that on a host, RSIP is associated with a TCP/IP stack implementation. 🔥 Modifications to IP tunneling and routing code, as well as driver interfaces may need to be made to support RSA-IP. Support for RSAP-IP requires modifications to ephemeral port selection code as well. 🎀 If a host has multiple TCP/IP stacks or TCP/IP stacks and other communication stacks, RSIP will only operate on the packets / sessions that are associated with the TCP/IP stack(s) that use RSIP. RSIP is not application specific, and if it is implemented in a stack, it will operate beneath all applications that use the stack. 👑

4. Deployment ✨

When RSIP is deployed in certain scenarios, the network characteristics of these scenarios will determine the scope of the RSIP solution, and therefore impact the requirements of RSIP. 🌸 In this section, we examine deployment scenarios, and the impact that RSIP may have on existing networks. 🔍

4.1. Possible Deployment Scenarios 🗺️

In this section we discuss a number of potential RSIP deployment scenarios. The selection below are not comprehensive and other scenarios may emerge. 🌈

4.1.1. Small / Medium Enterprise 🏢

Up to several hundred hosts will reside behind an RSIP-enabled router. 💼 It is likely that there will be only one gateway to the public network and therefore only one RSIP gateway. This RSIP gateway may control only one, or perhaps several, public IP addresses. The RSIP gateway may also perform firewall functions, as well as routing inbound traffic to particular destination ports on to a small number of dedicated gateways on the private network. 🔐

4.1.2. Residential Networks 🏠

This category includes both networking within just one residence, as well as within multiple-dwelling units. 🏘️ At most several hundred hosts will share the gateway's resources. In particular, many of these devices may be thin hosts or so-called "network appliances" and therefore not require access to the public Internet frequently. 🧸 The RSIP gateway is likely to be implemented as part of a residential firewall, and it may be called upon to route traffic to particular destination ports on to a small number of dedicated gateways on the private network. It is likely that only one gateway to the public network will be present and that this gateway's RSIP gateway will control only one IP address. Support for secure end-to-end VPN access to corporate intranets will be important. 🔒

4.1.3. Hospitality Networks ☕

A hospitality network is a general type of "hosting" network that a traveler will use for a short period of time (a few minutes or a few hours). ✈️ Examples scenarios include hotels, conference centers and airports and train stations. 🏨 At most several hundred hosts will share the gateway's resources. The RSIP gateway may be implemented as part of a firewall, and it will probably not be used to route traffic to particular destination ports on to dedicated gateways on the private network. It is likely that only one gateway to the public network will be present and that this gateway's RSIP gateway will control only one IP address. Support for secure end-to-end VPN access to corporate intranets will be important. 💅

4.1.4. Dialup Remote Access 📞

RSIP gateways may be placed in dialup remote access concentrators in order to multiplex IP addresses across dialup users. 🧩 At most several hundred hosts will share the gateway's resources. The RSIP gateway may or may not be implemented as part of a firewall, and it will probably not be used to route traffic to particular destination ports on to dedicated gateways on the private network. Only one gateway to the public network will be present (the remote access concentrator itself) and that this gateway's RSIP gateway will control a small number of IP addresses. Support for secure end-to-end VPN access to corporate intranets will be important. 🕰️

4.1.5. Wireless Remote Access Networks 📱

Wireless remote access will become very prevalent as more PDA and IP / cellular devices are deployed. 📲 In these scenarios, hosts may be changing physical location very rapidly - therefore Mobile IP will play a role. 🚶‍♀️ Hosts typically will register with an RSIP gateway for a short period of time. At most several hundred hosts will share the gateway's resources. The RSIP gateway may be implemented as part of a firewall, and it will probably not be used to route traffic to particular destination ports on to dedicated gateways on the private network. It is likely that only one gateway to the public network will be present and that this gateway's RSIP gateway will control a small number of IP addresses. Support for secure end-to-end VPN access to corporate intranets will be important. 🛡️

4.2. Cascaded RSIP and NAT 🪆

It is possible for RSIP to allow for cascading of RSIP gateways as well as cascading of RSIP gateways with NAT boxes. 🧁 For example, consider an ISP that uses RSIP for address sharing amongst its customers. It might assign resources (e.g., IP addresses and ports) to a particular customer. This customer may use RSIP to further subdivide the port ranges and address(es) amongst individual end hosts. No matter how many levels of RSIP assignment exists, RSIP MUST only assign public IP addresses. 🚨

Note that some of the architectures discussed below may not be useful or desirable. 🙃 The goal of this section is to explore the interactions between NAT and RSIP as RSIP is incrementally deployed on systems that already support NAT. 🔍✨

4.2.1. RSIP Behind RSIP 🪞

Okay bestie, here's the reference architecture 👀

                               +-----------+
                               |           |
                               |   RSIP    |
                               |  gateway  +---- 10.0.0.0/8
                               |     B     |
                               |           |
                               +-----+-----+
                                     |
                                     | 10.0.1.0/24
                      +-----------+  | (149.112.240.0/25)
                      |           |  |
      149.112.240.0/24|   RSIP    +--+
      ----------------+  gateway  |
                      |     A     +--+
                      |           |  |
                      +-----------+  | 10.0.2.0/24
                                     | (149.112.240.128/25)
                                     |
                               +-----+-----+
                               |           |
                               |   RSIP    |
                               |  gateway  +---- 10.0.0.0/8
                               |     C     |
                               |           |
                               +-----------+

So RSIP gateway A is in charge of the IP addresses in subnet 149.112.240.0/24. It hands those addresses out to RSIP hosts and RSIP gateways. In this setup, it gives 149.112.240.0 - 149.112.240.127 to RSIP gateway B and 149.112.240.128 - 149.112.240.254 to RSIP gateway C. The subnet broadcast address, 149.112.240.255, must remain unclaimed, so broadcast packets can still reach arbitrary hosts behind RSIP gateway A. Also, the subnets between gateway A and gateways B and C use private addresses 🔒

Because addresses get cascaded in a tree shape, gateway A is called the 'parent' of gateways B and C, and B and C are its 'children' ✨ You can have an arbitrary number of levels of children under a parent gateway, so the tree can go as deep as you want.

Here's the tricky bit: a parent gateway won't necessarily know that the addresses and port blocks it gave to a child are getting handed down even further. So RSIP hosts MUST tunnel their outgoing packets to the nearest RSIP gateway. That gateway then checks that the sending host used the right address and port block, and only then tunnels the packet on to its parent 💅

Let's walk through it. Host 10.0.0.1, sitting behind RSIP gateway C, uses its assigned external IP address (say, 149.112.240.130) and tunnels its packets over the 10.0.0.0/8 subnet to RSIP gateway C. RSIP gateway C strips off the outer IP header. After it verifies that the source public IP address and source port number are valid, RSIP gateway C tunnels the packets over the 10.0.2.0/8 subnet to RSIP gateway A. RSIP gateway A then strips off the outer IP header. After verifying the source public IP address and source port number, RSIP gateway A sends the packet out on the public network 🚀

Tunnelling straight to the overall parent of the gateway tree could be more efficient in terms of computation, but it would introduce significant state and administrative difficulties 😩 So that's a no from us.

A child RSIP gateway MUST take into consideration the parameter assignment constraints it inherits from its parent when it assigns parameters to its own children. For example, if a child RSIP gateway gets a lease time of 3600 seconds on an IP address, it MUST compare the current time to the lease time and to the time the lease was assigned. That lets it work out the maximum allowable lease time on the address if it's going to assign that address to an RSIP host or child RSIP gateway. Math bestie, it's giving careful 🧮

4.2.2. NAT Behind RSIP 🌸

               +--------+      +--------+
               | NAT w/ |      |  RSIP  |
   hosts ------+ RSIP   +------+ gate-  +----- public network
               | host   |      |  way   |
               +--------+      +--------+

In this architecture, an RSIP gateway sits between a NAT box and the public network. The NAT is also equipped with an RSIP host. The NAT dynamically requests resources from the RSIP gateway as the hosts establish sessions to the public network. The hosts aren't aware of any of the RSIP manipulation going on 🙈

Here's the catch: this setup doesn't give the hosts end-to-end transparency, so the NAT still needs ALGs, and the architecture can't support IPSEC 💀

4.2.3. RSIP Behind NAT 🧱

               +--------+      +--------+
   RSIP        |  RSIP  |      |        |
   hosts ------+ gate-  +------+   NAT  +----- public network
               |  way   |      |        |
               +--------+      +--------+

In this architecture, the RSIP hosts and the gateway both live behind a NAT. Same deal as before: no end-to-end transparency, so the NAT still needs ALGs, and IPSEC is still a no-go 😭

The hosts could get transparency, though, if there's another gateway to the public network besides the NAT box, and that gateway supports cascaded RSIP behind RSIP. Plot twist, but it works 🎀

4.2.4. RSIP Through NAT 🦋

               +--------+      +--------+
   RSIP        |        |      |  RSIP  |
   hosts ------+   NAT  +------+ gate-  +----- public network
               |        |      |  way   |
               +--------+      +--------+

In this architecture, the RSIP hosts are separated from the RSIP gateway by a NAT. RSIP signalling may be able to get through the NAT if an RSIP ALG is installed. The RSIP data flow, however, will have its outer IP address translated by the NAT. The NAT must not translate the port numbers for RSIP to work properly. So only traditional NAT makes sense in this context, bestie 🤷‍♀️

5. Interaction with Layer-Three Protocols 🧩

Since RSIP affects layer-three objects, it has an impact on other layer-three protocols. In this section, we go over how RSIP affects those protocols, and in each case, how RSIP, the protocol, or both can be extended so they work together 💜

Each of these sections is an overview, not a complete technical specification. If you need a full technical spec of how RSIP interacts with a layer-three protocol, a separate document will have it 📚

5.1. IPSEC 🔐

RSIP is a mechanism for allowing end-to-end IPSEC with sharing of IP addresses. The full specification of RSIP/IPSEC details is in [RSIP-IPSEC]. This section gives a brief summary, so you're getting the highlights ✨

Since IPSEC may encrypt TCP/UDP port numbers, those objects can't be used as demultiplexing fields. But IPSEC inserts an AH or ESP header after the IP header in all IPSEC-protected packets (packets sent on an IPSEC Security Association (SA)). These headers contain a 32-bit Security Parameter Index (SPI) field, whose value is determined by the receiving side. The SPI field is always in the clear 👀 So during SA negotiation, an RSIP host can tell its public peer to use a particular SPI value. That SPI value, together with the assigned IP address, can be used by an RSIP gateway to uniquely identify and route packets to an RSIP host. To guarantee that RSIP hosts use SPIs that are unique per address, the RSIP gateway needs to allocate unique SPIs to hosts along with their address/port tuple. Uniqueness is everything, periodt 💅

IPSEC SA negotiation happens using the Internet Key Exchange (IKE) protocol. IKE is designated to use port 500 on at least the destination side. Some host IKE implementations also use source port 500, but that behaviour isn't mandatory. If two or more RSIP hosts are running IKE at source port 500, they MUST use different initiator cookies (the first eight bytes of the IKE payload) per assigned IP address. The RSIP gateway can then route incoming IKE packets to the right host based on the initiator cookie value 🎯 Initiator cookies can be negotiated, just like ports and SPIs. Since it's really unlikely that two hosts with the same assigned IP address would try to use the same initiator cookie at the same time, the RSIP gateway can guarantee cookie uniqueness by dropping IKE packets whose cookie value is already in use 🫶

5.2. Mobile IP 📱

Mobile IP lets a mobile host keep an IP address as it moves from network to network. For Mobile IP foreign networks that use private IP addresses, RSIP may be applicable. In particular, RSIP would let a mobile host bind to a local private address while keeping a global home address and a global care-of address. The global care-of address could, in principle, be shared with other mobile nodes 🌍

The exact behaviour of Mobile IP with respect to private IP addresses has not been settled yet. Until it is, a proposal to adapt RSIP to that scenario is premature. Also, such an adaptation may be considerably complex. So integrating RSIP and Mobile IP is a topic of ongoing consideration 🤔

5.3. Differentiated and Integrated Services 🎀

To provide quality of service between two communicating hosts in different realms, it's important to consider how RSIP interacts with the different quality of service provisioning models and mechanisms. In this section, we talk about how RSIP interacts with the integrated services and differentiated services frameworks 🌈

5.3.1. Differentiated Services ✨

okay so the differentiated services architecture from [RFC2475] lets networks give several levels of best-effort service by "marking" the IP Type-of-Service (now DS) byte 🎀. Each value of the DS byte is a differentiated services code point (DSCP), and it stands for a particular per-hop behavior. ngl that behavior may not be the same in every administrative domain 🤷. And no explicit signaling is needed to make it work 💅.

For outbound packets leaving an edge network, DSCP marking is typically performed and/or enforced on a boundary router. The marked packet then gets forwarded onto the public network 🌸. In an RSIP-enabled network, the natural spot for DSCP marking is the RSIP gateway 🧚. With RSAP-IP, the gateway can use its micro-flow (address/port tuple) knowledge of RSIP assignments to give different service levels to different RSIP hosts 👑. With RSA-IP, the gateway won't necessarily know about micro-flows, so it must rely on markings made by the RSIP hosts (if any) or apply a default policy to the packets 🥹.

When differentiated services has to happen between RSIP hosts and gateways, it must be done over the tunnel between those entities. [DS-TUNN] covers differentiated services over a tunnel in full detail, so here we only need the tunnel ingress and egress behaviors for both incoming and going packets 🦋.

For incoming packets arriving at an RSIP gateway tunnel ingress, the RSIP gateway may either copy the DSCP from the inner header to the outer header, leave the inner header DSCP untouched but place a different DSCP in the outer header, or change the inner header DSCP while applying either the same or a different DSCP to the outer header. ✨

For incoming packets arriving at an RSIP host tunnel egress, behavior with respect to the DSCP is not necessarily important if the RSIP host not only terminates the tunnel but also consumes the packet 🙈. If that's not the case, like in some cascaded RSIP scenarios, the RSIP host must apply local policy to decide whether to leave the inner header DSCP as is, overwrite it with the outer header DSCP, or overwrite it with a different value 💜.

For outgoing packets arriving at an RSIP host tunnel ingress, the host may either copy the DSCP from the inner header to the outer header, leave the inner header DSCP untouched but place a different DSCP in the outer header, or change the inner header DSCP while applying either the same or a different DSCP to the outer header 🌈.

For outgoing packets arriving at an RSIP gateway tunnel egress, the RSIP gateway must apply local policy to decide whether to leave the inner header DSCP as is, overwrite it with the outer header DSCP, or overwrite it with a different value 🔥.

It's reasonable to assume that in most cases, the diffserv policy on a site will be the same for RSIP and non-RSIP hosts. For that reason, a likely policy is that the DSCP will always be copied between the outer and inner headers in all of the above cases 🫶. However, implementations should allow for the more general case 💅.

5.3.2. Integrated Services 🌈

The integrated services model from [RFC2205] requires signalling using RSVP to set up a resource reservation in intermediate nodes between the communicating endpoints. In the most common RSIP deployment, receivers inside the private realm start communication sessions with senders in the public realm 🦋. This section talks about how the RSIP architecture and RSVP interact in that scenario. The less common case, with senders in the private realm and receivers in the public realm, isn't discussed here, though the concepts mentioned may be applicable 🤍.

With senders in the public realm, RSVP PATH messages flow downstream from sender to receiver, inbound with respect to the RSIP gateway, while RSVP RESV messages flow the opposite way. Since RSIP uses tunneling between the RSIP host and gateway within the private realm, how the RSVP messages get handled inside the RSIP tunnel depends on the situations laid out in [RFC2746] 📦.

Following the terminology of [RFC2476], if Type 1 tunnels exist between the RSIP host and gateway, then all intermediate nodes, including the RSIP gateway, are treated as a non-RSVP aware cloud with no QoS reserved on those nodes 🌤️. The tunnel is viewed as a single (logical) link on the path between source and destination. End-to-end RSVP messages get forwarded through the tunnel encapsulated the same way as normal IP packets. We see this as the most common and applicable deployment scenario 👑.

However, if Type 2 or 3 tunnels are deployed between the tunneling endpoints, the end-to-end RSVP session has to be statically mapped (Type 2) or dynamically mapped (Type 3) into the tunnel sessions 🧠. The end-to-end RSVP messages still get forwarded through the tunnel encapsulated like normal IP packets, but a tunnel session is set up between the tunnel endpoints to make sure QoS is reserved inside the tunnel for the end-to-end session 🔐. Data traffic that needs special QoS assurance gets encapsulated in a UDP/IP header, while normal traffic uses the regular IP-IP encapsulation. In the Type 2 deployment scenario where all data traffic flowing to the RSIP host receiver gets QoS treatment, UDP/IP encapsulation is rendered in the RSIP gateway for all data flows. The tunnel between the RSIP host and gateway could be seen as a "hard pipe". Traffic exceeding the QoS guarantee of the "hard pipe" falls back to best-effort IP-IP tunneling 🍓.

In the Type 2 deployment scenario, where data traffic can be selectively channeled into either the UDP/IP or the normal IP-IP tunnel, or in the Type 3 deployment scenario, where end-to-end sessions can be dynamically mapped into tunnel sessions, integration with the RSIP model could get complicated and tricky 😭. (Note that these are the cases where the tunnel link could be seen as an expandable "soft pipe".) Two main issues are worth thinking about:

  • For RSIP gateway implementations that encapsulate the incoming stream before passing it to the IP layer for forwarding, the RSVP daemon has to be explicitly signaled when incoming RSVP PATH messages arrive. The RSIP implementation has to recognize RSVP PATH messages and hand them to the RSVP daemon instead of doing the default tunneling. Handling of other RSVP messages is as described in [RFC2746] 🛠️.
  • RSIP lets an RSIP host have a temporary presence at the RSIP gateway by assuming one of the gateway's global interfaces 🫣. As a result, the RSVP PATH messages are addressed to the RSIP gateway. Also, the SESSION object inside an incoming RSVP PATH message carries the global destination address and destination port (and protocol) tuples that the RSIP gateway leased to the RSIP host. So the realm-unaware RSVP daemon running on the RSIP gateway has to be given a translated version of the RSVP messages. Other approaches are possible, such as making the RSVP daemon realm aware 🌷.

A simple mechanism would be to have the RSIP module handle the necessary RSVP message translation 💖. For an incoming RSVP signalling flow, the RSIP module translates the IP header and the RSVP SESSION object before handing the packet over to RSVP. The global address leased to the host gets translated to the host's true private address. (Note that this mechanism works with both RSA-IP and RSAP-IP.) The RSIP module also has to do the opposite translation, from private to global parameters (plus tunneling), for end-to-end PATH messages generated by the RSVP daemon toward the RSIP host receiver. A translation on the SESSION object also has to be done for RSVP outbound control messages. Once the RSVP daemon gets the message, it maps it to an appropriate tunnel session 🧚.

Encapsulation of inbound data traffic that needs QoS treatment is done using UDP-IP encapsulation, as designated by the tunnel session. For this reason, the RSIP module has to be aware of the UDP-IP encapsulation to use for a particular end-to-end session. Classification and scheduling of the QoS-guaranteed end-to-end flow on the RSIP gateway's output interface are based on the UDP/IP encapsulation. Mapping between the tunnel session and the end-to-end session could continue to use the mechanisms proposed in [RFC2746]. Although [RFC2746] proposes a number of approaches for this, we propose using the SESSION_ASSOC object, because of its simplicity 🎀.

5.4. IP Multicast 💜

The amount of specific RSIP/multicast support required in RSIP hosts and gateways depends on the scope of multicasting in the RSIP-enabled network and on the roles the RSIP hosts will play. This section talks through RSIP and multicast interactions in a number of scenarios 🌸.

Note that in all cases, the RSIP gateway MUST be multicast aware, because it sits on an administrative boundary between two domains that won't be sharing all of their routing information 🚧. The RSIP gateway MUST NOT allow private IP addresses to be propagated on the public network, whether as part of any multicast message or as part of a routing table 🔒.

5.4.1. Receiving-Only Private Hosts, No Multicast Routing on Private Network 🍓

In this scenario, private hosts won't source multicast traffic, but they may join multicast groups as recipients. On the private network, there are no multicast-aware routers except for the RSIP gateway 🙌.

Private hosts may join and leave multicast groups by sending the appropriate IGMP messages to an RSIP gateway (there may be IGMP proxy routers between RSIP hosts and gateways) 🧃. The RSIP gateway coalesces these requests and performs the appropriate actions. Those might be running a multicast WAN routing protocol, such as PIM, or proxying the IGMP messages to a WAN multicast router. In other words, if one or more private hosts request to join a multicast group, the RSIP gateway MUST join in their stead, using one of its own public IP addresses 🥳.

Note that private hosts don't need to acquire demultiplexing fields and use RSIP to receive multicasts. They can receive all multicasts using their private addresses, and that private address is how the RSIP gateway keeps track of their group membership 💅✨.

5.4.2. Sending and Receiving Private Hosts, No Multicast Routing on Private Network ✨

Okay so this one works basically the same as the last scenario 💅, except for one big change: when a private host becomes a multicast source, it MUST use RSIP and grab a public IP address 🌸 (it'll still receive on its private address though 🫶). A private host sending a multicast uses that public source address and tunnels the packets to the RSIP gateway 🦋. The RSIP gateway then does its typical RSIP thing and routes the packets onto the public network, and also back to the private network if anyone over there is listening 👀.

If there's more than one sender on the private network, then from the public network's point of view, it's giving everyone shares one IP address 🙈. If a downstream multicasting protocol identifies sources by IP address alone and not port numbers, it's possible those protocols won't be able to tell the senders apart 💀.

6. RSIP Complications 💥

Here we're spilling all the known complications RSIP can cause 🫣. None of these are "show stoppers" for most apps, but they may lead to unexpected or undefined behavior. Where it makes sense, we talk about possible remedies that might shrink or wipe out the damage 🩹.

6.1. Unnecessary TCP TIME_WAIT ⏳

When TCP closes a socket, it enters the TIME_WAIT state for a while 😴. During that time it refuses to accept new connections on the same socket (aka the same source address/port and destination address/port). Picture this: an RSIP host (using RSAP-IP) gets leased an address/port tuple and uses it to contact a public address/port tuple. Then the host ends the session with the public tuple and immediately gives its leased tuple back to the RSIP gateway. If the gateway instantly hands that tuple to another RSIP host (or the same host again), and this second host uses it to contact the same public tuple while the socket is still in TIME_WAIT, the public host might reject the connection 😭.

To help with this, it is recommended that RSIP gateways hold recently deallocated tuples for at least two minutes, which is the longest TIME_WAIT duration that's commonly implemented ⏰. When port space is running low, the RSIP gateway MAY choose to allocate ports in a FIFO fashion from the pool of recently deallocated ports 🎀.

6.2. ICMP State in RSIP Gateway 🛰️

Just like NAT, RSIP gateways providing RSAP-IP must process ICMP responses from the public network so they know which RSIP host (if any) is the right recipient 🎯. Quick distinction: ICMP error packets get sent in response to an error with an associated IP packet, while ICMP response packets get sent in response to an ICMP request packet 🧠.

ICMP request packets coming from the private network are usually echo request, timestamp request and address mask request. These packets and their responses can be identified by the tuple of source IP address, ICMP identifier, ICMP sequence number, and destination IP address 🔍. An RSIP host sending an ICMP request packet tunnels it to the RSIP gateway, the same way it does TCP and UDP packets 🚇. The RSIP gateway must use this tuple to map incoming ICMP responses to the private address of the right RSIP host. Once it's matched them up, it tunnels the ICMP response over to the host 📦. Heads up though: two RSIP hosts can use the same values for those tuple fields, which creates an ambiguity. This is likely to be pretty rare, though, so this document doesn't go further into it 🤷‍♀️.

Incoming ICMP error response messages can be forwarded to the right RSIP host by checking the IP header and port numbers embedded inside the ICMP packet 🕵️‍♀️. If those fields aren't there, the packet should be silently discarded 🫥.

Sometimes an RSIP host has to send an ICMP response of its own (like port unreachable) 📣. These get tunneled to the RSIP gateway, just like TCP and UDP packets do. All ICMP requests (like echo request) arriving at the RSIP gateway MUST be processed by the gateway and MUST NOT be forwarded to an RSIP host 🚫.

6.3. Fragmentation and IP Identification Field Collision 🧩

If two or more RSIP hosts on the same private network send outbound packets that get fragmented on their way to the same public gateway, the public gateway may run into a reassembly ambiguity if the IP header ID fields of those packets are identical 😵‍💫.

For TCP packets, you can set a reasonably small MTU so fragmentation is guaranteed not to happen, or so it's extremely unlikely 📏. If path MTU discovery works properly, the problem gets better too ✨. For UDP, the applications control the packet size, so the RSIP host stack may have to fragment UDP packets that go over the local MTU 🫠. Intermediate routers might fragment them as well 🛤️.

The only totally robust fix is to give every RSIP host sharing the same public IP address its own disjoint block of numbers to use in the IP identification fields 🎟️. Whether that change is worth the effort to implement is currently unknown 🤔.

6.4. Application Servers on RSAP-IP Hosts 🖥️

RSAP-IP hosts have the same limits NAT has when it comes to hosting servers on a well-known port 🚧. Since destination port numbers are used as routing info to uniquely identify an RSAP-IP host, usually no two RSAP-IP hosts sharing the same public IP address can run publicly available gateways on the same port at the same time 🙅‍♀️. For protocols on well-known ports, that means only one public gateway per RSAP-IP IP address / port tuple is used at a time. More than one gateway per RSAP-IP IP address / port tuple can be used at once only if there's a demultiplexing field in the payload of all packets that uniquely determines the RSAP-IP host, and the RSIP gateway knows about that field 🔑.

To run a publicly available gateway, an RSAP-IP host has to tell the RSIP gateway that it wants all traffic going to that port number, for its IP address 📨. Such a request MUST be denied if the port in question is already in use by another host 🚫.

Honestly, contacting devices behind an RSIP gateway can be a lot 😩. One possible fix for the general problem would be an architecture where an application on an RSIP host registers a public IP address / port pair in a public database 🗄️. At the same time, the RSIP gateway would set up a mapping from that address / port tuple to the RSIP host. Then a peer application would have to check the database to find the right address / port to contact the RSIP host's application 🔎.

6.5. Determining Locality of Destinations from an RSIP Host 🗺️

In general, an RSIP host must know, for a particular IP address, whether to address the packet for local delivery on the private network, or whether it has to use an RSIP interface to tunnel to an RSIP gateway (assuming it has one available) 🧭.

If all the RSIP hosts are on a single subnet, one hop away from an RSIP gateway, then checking the local network and subnet mask will give the right info 📍. But that's not always the case 😬.

An approach that works in general for statically addressed private networks is to store a list of the network and subnet masks of every private subnet at the RSIP gateway 📚. RSIP hosts may query the gateway with a particular target IP address, or ask for the entire list 🙋‍♀️.

If the subnets on the local side of the network change faster than the lifetime of a typical RSIP session, the RSIP host may have to query the location of every destination it tries to talk to 🏃‍♀️💨.

If an RSIP host sends a packet to a public host without using RSIP, then the RSIP gateway will apply NAT to the packet (if it supports NAT), or it may discard the packet and respond with an appropriate ICMP message 📬.

A robust fix for this has proven hard to develop 😤. Right now, it isn't known how severe this problem is. It will likely be worse on networks where the routing info changes rapidly than on networks with relatively static routes 🌪️.

6.6. Implementing RSIP Host Deallocation 🧹

An RSIP host MAY free resources that it has determined it no longer requires 🗑️. For example, on an RSAP-IP subnet with a limited number of public IP addresses, port numbers can get scarce 🏜️. So if RSIP hosts can dynamically deallocate the ports they don't need, more hosts can be supported 🙌.

That said, this functionality may need significant changes to a vanilla TCP/IP stack to work properly 🛠️. The RSIP host has to be able to figure out which TCP or UDP sessions are using RSIP resources. If those resources sit unused for a while, the RSIP host may deallocate them. When an open socket's resources get deallocated, some associated applications will fail 💥. It's kind of like TCP and UDP sessions that have to end when an interface they're using loses connectivity 🔌.

On the flip side, this can be treated as a resource allocation problem 📊. It is not recommended that a large number (hundreds) of hosts share the same IP address, for performance reasons 🐌. Even if, say, 100 hosts each get 100 ports, the total ports in use by RSIP would still be less than one-sixth of the total port space for an IP address 🧮. If more hosts or more ports are needed, more IP addresses should be used 🌈. So it's reasonable that in many cases, RSIP hosts won't have to deallocate ports for the entire lifetime of their activity 💅.

Since RSIP demultiplexing fields are leased to hosts, a well-chosen lease time can ease some of the port space scarcity 🎁.

6.7. Multi-Party Applications 👯

Multi-party applications are defined as having at least one of these characteristics:

  • A third party sets up sessions or connections between two hosts 🤝.
  • Computation is distributed over a number of hosts, so the individual hosts may communicate with each other directly 🧩.

RSIP has a fundamental problem with multi-party apps 😵. If some parties are in the private addressing realm and others are in the public one, an RSIP host may not know when to use private addresses versus public addresses 🫣. In particular, IP addresses may get passed from party to party under the assumption that they're global endpoint identifiers. That can make multi-party applications fail 💔.

There's no known solution to this general problem yet 😭. Remedial measures exist, though, like forcing all RSIP hosts to always use public IP addresses, even when they're only talking to other RSIP hosts 🌍. But this can result in a socket set up between two RSIP hosts having the same source and destination IP addresses, which most TCP/IP stacks will treat as intra-host communication 🙃.

6.8. Scalability ✨

okay so scalability for RSIP is honestly not well understood yet 🥺. Like, it's conceivable that one RSIP gateway could handle hundreds of RSIP hosts, but it really depends on the deployment and which apps are being used 💅. The three big constraints are (1) RSIP gateway processing requirements, (2) RSIP gateway memory requirements, and (3) RSIP negotiation protocol traffic requirements. So it's advisable that every RSIP negotiation protocol implementation tries to keep all of these as low as possible 🫶

7. Security Considerations 🔐

bestie, listen up 👂 RSIP, all by itself, does not provide security 🚨. It can give you the illusion of security or privacy because it hides a private address space, but that's just vibes 🙈. Real security only comes from using proper security protocols and cryptographic techniques 🔒✨

8. Acknowledgements 🫶

the authors wanted to thank Pyda Srisuresh, Dan Nessett, Gary Jaszewski, Ajay Bakre, Cyndi Jung, and Rick Cobb for their input 💖. And the IETF NAT working group as a whole has been extremely helpful in the ongoing development of RSIP 🌈. Such a supportive squad, I'm obsessed 😭

9. References 📚

  • [DHCP-DNS] Stapp, M. and Y. Rekhter, "Interaction Between DHCP and DNS", Work in Progress.
  • [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
  • [RFC3104] Montenegro, G. and M. Borella, "RSIP Support for End-to-End IPSEC", RFC 3104, October 2001.
  • [RFC3103] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001.
  • [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
  • [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
  • [RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
  • [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
  • [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP)", RFC 2205, September 1997.
  • [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
  • [RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with SLP", RFC 3105, October 2001.

10. Authors' Addresses 💌

the squad behind it all 🦋 (contact info copied exactly, obviously 💅):

Michael Borella
CommWorks
3800 Golf Rd.
Rolling Meadows IL 60008

Phone: (847) 262-3083
EMail: mike_borella@commworks.com


Jeffrey Lo
Candlestick Networks, Inc
70 Las Colinas Lane,
San Jose, CA 95119

Phone: (408) 284 4132
EMail: yidarlo@yahoo.com


David Grabelsky
CommWorks
3800 Golf Rd.
Rolling Meadows IL 60008

Phone: (847) 222-2483
EMail: david_grabelsky@commworks.com


Gabriel E. Montenegro
Sun Microsystems
Laboratories, Europe
29, chemin du Vieux Chene
38240 Meylan
FRANCE

Phone: +33 476 18 80 45
EMail: gab@sun.com

Okay, legal stuff, but it's still important 🎀

Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌸

the funding for the RFC Editor function is currently provided by the Internet Society 💖 and that's a wrap, bestie 🎀✨

📦 where this page comes from