RFC 3103
Realm Specific IP: Protocol Specification
RFC 3103: Realm Specific IP: Protocol Specification 🦋
Okay bestie, this is RFC 3103 ✨, and it's titled Realm Specific IP: Protocol Specification. It was written by M. Borella, D. Grabelsky, J. Lo and K. Taniguchi from CommWorks, Candlestick Networks and NEC USA, for the Network Working Group, and it's dated October 2001. It's in the Experimental category 🧪, and its title block doesn't list anything it obsoletes or updates. Let's get into it 💅
Status of This Memo 🌸
So this memo defines an Experimental Protocol for the Internet community 🧪. It does not specify an Internet standard of any kind, so don't go treating it like one 🙈 The authors are asking for discussion and suggestions for improvement, and distribution of the memo is unlimited 💜
Copyright Notice 🎀
Copyright (C) The Internet Society (2001). All Rights Reserved. 📜
IESG Note 🚨
The IESG is flagging that the set of documents describing RSIP technology implies significant host and gateway changes for a complete implementation 😭 Also, port numbers floating around can cause problems for some applications, which can stop an RSIP-enabled host from interoperating transparently with existing applications in some cases, IPsec being the example they give 🔐 Finally, there may be significant operational complexities involved in using RSIP 💀 Some of these complications (and others) are outlined in section 6 of RFC 3102, and also in the Appendices of RFC 3104. So the costs and benefits should be carefully weighed against other ways of relieving address shortage ⚖️ Be careful, bestie 🫶
Abstract ⭐
This document presents a protocol for implementing Realm Specific IP (RSIP) 🦋 The protocol lets an RSIP host and gateway negotiate resources, so the host can lease some of the gateway's addressing parameters and get a global network presence 🌍 It's designed to run at the application layer and to use its own TCP or UDP port 🔌 The big point is that the protocol lets a gateway hand addressing and control parameters to a host, so a flow policy can be enforced at the gateway 👑
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Transport Protocol . . . . . . . . . . . . . . . . . . . . . 7
6. Host / Gateway Relationships . . . . . . . . . . . . . . . . 7
7. Gateway Flow Policy and State . . . . . . . . . . . . . . . . 8
7.1. Local Flow Policy . . . . . . . . . . . . . . . . . . . . . 9
7.2. Remote Flow Policy . . . . . . . . . . . . . . . . . . . . 9
7.3. Gateway State . . . . . . . . . . . . . . . . . . . . . . . 10
8. Parameter Specification and Formats . . . . . . . . . . . . . 11
8.1. Address . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Lease Time . . . . . . . . . . . . . . . . . . . . . . . . 13
8.4. Client ID . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.5. Bind ID . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.6. Tunnel Type . . . . . . . . . . . . . . . . . . . . . . . . 14
8.7. RSIP Method . . . . . . . . . . . . . . . . . . . . . . . . 14
8.8. 8.8. Error . . . . . . . . . . . . . . . . . . . . . . . . 14
8.9. Flow Policy . . . . . . . . . . . . . . . . . . . . . . . . 15
8.10. Indicator . . . . . . . . . . . . . . . . . . . . . . . . 15
8.11. Message Counter . . . . . . . . . . . . . . . . . . . . . 16
8.12. Vendor Specific Parameter . . . . . . . . . . . . . . . . 16
9. Message Types . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. ERROR_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 17
9.2. REGISTER_REQUEST . . . . . . . . . . . . . . . . . . . . . 18
9.3. REGISTER_RESPONSE . . . . . . . . . . . . . . . . . . . . . 19
9.4. DE-REGISTER_REQUEST . . . . . . . . . . . . . . . . . . . . 19
9.5. DE-REGISTER_RESPONSE . . . . . . . . . . . . . . . . . . . 20
9.6. ASSIGN_REQUEST_RSA-IP . . . . . . . . . . . . . . . . . . . 21
9.7. ASSIGN_RESPONSE_RSA-IP . . . . . . . . . . . . . . . . . . 22
9.8. ASSIGN_REQUEST_RSAP-IP . . . . . . . . . . . . . . . . . . 23
9.9. ASSIGN_RESPONSE_RSAP-IP . . . . . . . . . . . . . . . . . . 26
9.10. EXTEND_REQUEST . . . . . . . . . . . . . . . . . . . . . . 27
9.11. EXTEND_RESPONSE . . . . . . . . . . . . . . . . . . . . . 28
9.12. FREE_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 28
9.13. FREE_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 29
9.14. QUERY_REQUEST . . . . . . . . . . . . . . . . . . . . . . 30
9.15. QUERY_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 31
9.16. LISTEN_REQUEST . . . . . . . . . . . . . . . . . . . . . . 32
9.17. LISTEN_RESPONSE . . . . . . . . . . . . . . . . . . . . . 35
10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Use of Message Counters . . . . . . . . . . . . . . . . . 36
10.2. RSIP Host and Gateway Failure Scenarios . . . . . . . . . 37
10.3. General Gateway Policy . . . . . . . . . . . . . . . . . . 38
10.4. Errors Not From the RSIP Protocol . . . . . . . . . . . . 39
10.5. Address and Port Requests and Allocation . . . . . . . . . 40
10.6. Local Gateways and Flow Policy Interaction . . . . . . . . 40
11. Security Considerations . . . . . . . . . . . . . . . . . . 40
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
14. Appendix A: RSIP Error Numbers . . . . . . . . . . . . . . . 42
15. Appendix B: Message Types . . . . . . . . . . . . . . . . . 44
16. Appendix C: Example RSIP host/gateway transactions . . . . . 45
17. Appendix D: Example RSIP host state diagram . . . . . . . . 50
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
19. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53
20. Full Copyright Statement . . . . . . . . . . . . . . . . . . 541. Introduction ✨
Network Address Translation (NAT) has become really popular 🔥 as a way to separate public and private address spaces and ease network address shortages. A NAT translates the addresses of packets leaving a first routing realm into an address from a second routing realm, and does the reverse for packets coming back in from the second realm 🔁 The hosts on either side don't have to know this is happening, and it can change TCP/UDP port numbers and IP addresses in packets that go through the NAT 🫣
A NAT doesn't need hosts to be aware of the translation, but it will need an application layer gateway (ALG) for any protocol that carries IP addresses or port numbers in its packet payloads, like FTP 🙃 A NAT also won't work with protocols that need IP addresses and ports to stay unmodified between source and destination hosts, or with protocols that stop those changes from happening, like some IPsec modes or application-layer end-to-end encryption 🔐
Now, the alternative to a NAT is an architecture where hosts in the first (e.g., private) routing realm can directly use addresses and other routing parameters from the second (e.g., public) routing realm 👑 That's where RSIP [RSIP-FRAME] comes in. It's been defined as a method of address sharing that's more transparent than NAT 🦋 RSIP requires that an RSIP gateway (a router or gateway between the two realms) assign at least one address from the second routing realm, and maybe some other resources, to each RSIP host 🎁 An RSIP host is a host in the first routing realm that needs end-to-end connectivity to a host, entity or device in the second routing realm. So the second realm isn't directly reachable from the RSIP host, but the system still lets packets keep their integrity all the way from the RSIP host to their destination 💖 And ALGs are not required in the RSIP gateway, which is a big win 🥳
RSIP also requires that hosts be modified so they put some number of layer three, layer four or other values, the ones assigned by the RSIP gateway, into each packet bound for the second routing realm 🛠️
This document talks about a method for assigning parameters to an RSIP host from an RSIP gateway 🧚 The requirements, scope and applicability of RSIP, plus how it interacts with other layer 3 protocols, are covered in a companion framework document [RSIP-FRAME] 📚 Extensions to this protocol that enable end-to-end IPsec are discussed in [RSIP-IPSEC] 🔐
2. Specification of Requirements 💅
Okay, the keywords are the important part here 🫶 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "SHALL", "SHALL NOT", "MAY" and "MAY NOT" that show up in this document are to be interpreted as described in [RFC2119] 📖 Read those carefully, bestie 👀
3. Terminology 🎀
Let's do the vocab, it's going to be useful for everything after this 🧠
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 unique network addresses assigned by the Internet Assigned Number Authority (IANA) or an equivalent address registry 🏛️
RSIP Host 💻
A host within the private realm that acquires publicly unique parameters from an RSIP gateway through the use of the RSIP client/server protocol 🫶
RSIP Gateway 🚪
A router sitting on the boundary between a private realm and a public realm, which owns one or more public IP addresses ✨ An RSIP gateway is responsible for public parameter management and for assigning them to RSIP hosts 👑 An RSIP gateway may also act as a NAT router for hosts inside the private realm that aren't 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 where each RSIP host is allocated a unique IP address from the public realm. It's discussed in detail in [RSIP-FRAME] 💜
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. Also discussed in detail in [RSIP-FRAME] 🧚
Binding 🔗
An association of some combination of a local address, one or more local ports, a remote address, and a remote port with an RSIP host 🎀
Resource 🎁
A general way to refer to an item that an RSIP host leases from an RSIP gateway, e.g., an address or port 🍓
All other terminology found in this document is consistent with that of [RFC2663] and [RSIP-FRAME] 📚
4. Architecture ✨
okay so, to keep things simple for the rest of this doc, we're gonna assume the RSIP hosts in the first routing realm (network) use private IP addresses (see [RFC1918] 💅), and the second routing realm (network) uses public IP addresses. this assumption is made without loss of generality, so everything we talk about still applies to more general cases 🫶. the RSIP gateway connects the public and private realms and has an interface to each one. other NAT terminology in this doc is defined in [RFC2663] 🤓
here's an exemplary reference architecture for RSIP, bestie 🦋
RSIP Host RSIP Gateway Host
Xa Na Nb Yb
[X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y]
( Network ) ( Network )so hosts X and Y belong to different addressing realms, A and B, respectively. N is an RSIP gateway (which may also perform NAT functions 👀). N has two interfaces: Na on address space A, and Nb on address space B. N may 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. these addresses aren't shown in the diagram above, but they can be denoted as Nb1, Nb2, Nb3 and so on 🌸
now, host X needs to set up an end-to-end connection to a network entity Y that lives in address space B. first, X negotiates and gets assigned resources from the RSIP gateway. once those parameters are assigned, the RSIP gateway creates a mapping of X's addressing information and the assigned resources. this binding is what lets the gateway correctly de-multiplex and forward inbound traffic that Y generates for X 💖 every bind also has a lease time associated with it ⏳
using the public parameters the RSIP gateway assigned, RSIP hosts tunnel data packets across address space A to the RSIP gateway. the gateway is the end point of these tunnels, so it strips off the outer headers and routes the inner packets onto the public realm 🎀 as we mentioned earlier, the RSIP gateway keeps a mapping of the assigned public parameters as demultiplexing fields, which uniquely map them to RSIP host private addresses. when a packet from the public realm shows up at the gateway and matches a given set of demultiplexing fields, the gateway tunnels it to the right RSIP host 🧚 the tunnel headers of outbound packets from X to Y, given that X has been assigned Nb, look like this:
+---------+---------+---------+
| X -> Na | Nb -> Y | payload |
+---------+---------+---------+there are two basic flavors of RSIP: RSA-IP and RSAP-IP 🍓 RSIP hosts and gateways MUST support RSAP-IP and MAY support RSA-IP. the details of RSA-IP and RSAP-IP are in [RSIP-FRAME] 📚
5. Transport Protocol 🚚
RSIP is an application layer protocol, which means it needs a transport layer protocol to deliver its packets end-to-end 💅
RSIP gateways MUST support TCP, and SHOULD support UDP 🫶 since RSIP may be deployed across a wide variety of network links, RSIP hosts SHOULD support TCP, because TCP is robust across all those different kinds of links 💪 that said, RSIP hosts MAY support UDP instead of TCP, or both UDP and TCP 🌈
for RSIP hosts and gateways using UDP, timeout and retransmissions MUST occur ⏰ we recommend a binary exponential backoff scheme with an initial duration of 12.5 ms, and a maximum of six retries (seven total attempts before failure) 🔥 however, these parameters MAY be adjusted or tuned for specific link types or scenarios ✨
once a host and gateway have registered using either TCP or UDP, they may not switch between the two protocols for the rest of that registration 🙅 the client decides whether to use TCP or UDP, and that choice is determined by the transport protocol of the first packet the client sends in a successful registration procedure 🎯
6. Host / Gateway Relationships 👑
an RSIP host can be in exactly one of three fundamental relationships with an RSIP gateway:
- Unregistered: the RSIP gateway doesn't know the RSIP host exists, so it won't forward or deliver globally addressed packets on the host's behalf 🙈 the only valid RSIP-related action the host can take in this state is to request registration with an RSIP gateway.
- Registered: the RSIP gateway knows about the RSIP host, has given it a client ID, and has specified the flow policies it requires of the host 🧾 but no resources, like addresses or ports, have been allocated to the host yet, and the gateway still won't forward or deliver globally addressed packets for it 😭 every registration has an associated lease time, and if that lease expires, the RSIP host automatically goes back to the unregistered state.
- Assigned: the RSIP gateway has granted one or more bindings of resources to the host 🎀 the gateway will forward and deliver globally addressed packets on the host's behalf. each binding has an associated lease time, and if that lease expires, the binding is automatically revoked.
it's possible to have an architecture where an RSIP host is registered with more than one RSIP gateway at once 🦋 in those cases, the RSIP host can be in different relationships with different RSIP gateways at the same time 💜
an RSIP gateway MAY redirect an RSIP host to use a tunnel endpoint for data traffic that isn't the RSIP gateway itself, or that's perhaps a different interface on the RSIP gateway 🧚 this is done by putting the tunnel endpoint's address into an assignment. in an architecture like this, it's desirable (though not necessary) for the RSIP gateway to have a way to notify the tunnel endpoint about assignments and whether they've expired 📣
lease times for bindings and registrations are managed like this 🗓️ all lease times are given in units of seconds from the current time, which tells you when in the future the lease will expire. we'll use these expiration times in the discussion ahead 💖
a registration gets an initial expiration time, R. under that registration, multiple bindings can be established, each with its own expiration time (B1, B2, ...) 🍰 whenever a binding is established or extended, the registration expiration time gets adjusted so the registration lasts at least as long as the longest lease. in other words, when binding Bi is established or extended, this calculation happens: R = max(R, Bi) 🧮
with this scheme, a registration will never expire while any binding's lease is still valid 🛡️ however, a registration may expire when the last binding's lease expires, or at some point after that 🌙
7. Gateway Flow Policy and State 🌸
an RSIP gateway is likely to sit on the boundary between two or more different administrative domains, so it's desirable to let the gateway enforce flow-based policy 💅 in other words, an RSIP gateway should be able to explicitly control which local addresses and ports are used to communicate with remote addresses and ports 🔥
here's the vocab: macro-flow policy controls flow policy at the granularity level of IP addresses, while micro-flow policy controls flow policy at the granularity of IP address and port tuples 🧠 of course, there might be no policy at all, which means the RSIP gateway doesn't care what flow parameters RSIP hosts use 🤷♀️ we're going to look at two levels of local flow policy and three levels of remote flow policy 💜
7.1. Local Flow Policy 🎀
local flow policy decides how much control an RSIP gateway has over the local addressing parameters an RSIP host uses for particular sessions ✨
since an RSIP host must use at least an IP address allocated by the gateway, the loosest level of local flow policy is macro-flow based 🧁 under local macro-flow policy, an RSIP host gets an IP address (RSA-IP), or an IP address plus one or more ports to use with it (RSAP-IP) 🦋 the host can use those ports however it likes for setting up sessions with public hosts 🌈
under micro-flow policy, a host is allocated exactly one port at a time 🎯 the host can request more ports, also one at a time. this gives the gateway super tight control over local port use, although the host gets less flexibility 😤
note that only local macro-flow policy can be used with RSA-IP, while either local macro-flow or local micro-flow policy may be used with RSAP-IP 🍓
examples of how RSIP flow policy works are in Appendix C 📖
7.2. Remote Flow Policy 🌍
remote flow policy decides how much control an RSIP gateway has over the remote (public) hosts an RSIP host talks to 💁♀️ specifically, remote flow policy dictates how much detail a host has to specify about a remote host's or application's addressing parameters before the RSIP gateway lets the host communicate with it 🫶
the simplest and loosest form of flow policy is no policy at all 🕊️ the RSIP gateway hands out addressing parameters to the host, and the host can use them to talk to any remote host without explicitly telling the gateway 🎉
macro-flow policy requires the host to identify the remote address it wants to communicate with as part of its request for local addressing parameters 📬 if the request is granted, the host MUST use the specified local parameters only with the remote address specified, and MUST NOT communicate with the remote address using any local parameters other than the ones allocated 🚫 however, the host can contact any port number at that remote host without explicitly notifying the gateway 💌
micro-flow policy requires the host to identify the remote address and port it wants to communicate with as part of its request for local addressing parameters 🔐 if the request is granted, the host MUST use the specified local parameters only with the remote address and port specified, and MUST NOT communicate with that remote address and port using any local parameters other than the ones allocated 🛑
remote flow policy is implemented in both the ingress and egress directions, relative to where the RSIP gateway is located 🔄
7.3. Gateway State 🗂️
an RSIP gateway must keep state for all RSIP hosts and their assigned resources 📋 how much state, and what type, depends on the local and remote flow policy 🎭 the required gateway state varies based on the RSIP method, but it will always include the chosen method's demultiplexing parameters 🧩
7.3.1. RSA-IP State 💖
an RSIP gateway serving an RSIP host using the RSA-IP method MUST maintain the following minimum state, so that incoming packets get mapped properly to RSIP hosts 🎀
- Host's private address
- Host's assigned public address(es)
7.3.2. RSAP-IP State 🌟
an RSIP gateway serving an RSIP host using the RSAP-IP method MUST maintain the following minimum state, so that incoming packets get mapped properly to RSIP hosts 💅
- Host's private address
- Host's assigned public address(es)
- Host's assigned port(s) per address
7.3.3. Flow State 🌸
okay so, whether the gateway is doing RSA-IP or RSAP-IP, it needs extra state if it's using micro-flow or macro-flow based remote policy 🫶
if the gateway is using macro-flow based remote policy, it must keep track of:
- Remote host's address
if it's using micro-flow based remote policy, it must keep track of:
- Remote host's address
- Remote host's port
an RSIP gateway MAY keep more state if it wants 🦋 for example, it can record ToS/DS bytes to help with quality of service support 💅
8. Parameter Specification and Formats ✨
bestie, this section is where we define the formats for RSIP parameters 🎀 every RSIP message carries one or more parameters that pass info between the host and the gateway. every parameter is TLV (type-length-value): a 1-byte type, then a 2-byte length, then a value that's length bytes long 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the value field can be split up into other fields depending on the parameter type 🍓 quick heads up: the length field counts the bytes in the value field, not the whole parameter 👀
8.1. Address 🏡
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length | Addrtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address...
+-+-+-+-+-+-+-+-+-+-+-+the address parameter holds addressing info: an IPv4 address or netmask, an IPv6 address or netmask, or a fully qualified domain name (FQDN) 🌐 the Addrtype field is 1 byte and tells you which kind of address you're looking at.
Addrtype Length of address field (in bytes)
---- --------------------------------
0 Reserved 0
1 IPv4 4
2 IPv4 netmask 4
3 IPv6 16
4 FQDN variesfor FQDN (Fully qualified domain name), the address field length is one less than the value of the length field, and the name is an ASCII string with no terminating character 🔤
sometimes you need a "don't care" address 🙈 that's signified by setting the length field to 1 and leaving out the value field.
it is not valid for a host to request an address with an FQDN type as its local address (See specification of ASSIGN_REQUEST_RSA-IP and ASSIGN_REQUEST_RSAP-IP, below). 🚫
8.2. Ports 🚪
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port number | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the ports parameter encodes zero or more TCP or UDP ports 🔌 when there's a single port, the Number field is 1 and one port field follows it. when there's more than one port, the Number field tells you the total count, and the parameter can take one of two forms. if there's one port field, the ports are contiguous, starting at the port number in that field. or there can be as many port fields as the Number field says. you can work out how many port fields there are from the length field 🧮
sometimes you need a don't care value for one or more ports (like when a client app is using ephemeral source ports 🌈). to do that, set the length field to 1, set the Number field to however many ports you need, and leave out all the port fields. the value of the Number field MUST be greater than or equal to one.
if micro-flow based policy applies to a given ports parameter, it MUST contain exactly one port field 💜
8.3. Lease Time ⏰
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length = 4 | Lease time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the lease time parameter specifies the length, in seconds, of an RSIP host registration or parameter binding ⏳
8.4. Client ID 🪪
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length = 4 | Client ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the client ID parameter specifies an RSIP client ID. Client ID's by an RSIP gateway to differentiate RSIP hosts 🧑💻
8.5. Bind ID 🔗
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Length = 4 | Bind ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bind ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the bind ID parameter specifies an RSIP bind ID. Bind ID's are used by RSIP hosts and gateways to tell apart an RSIP host's bindings 🧩
8.6. Tunnel Type 🚇
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 1 | Tunnel type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the tunnel type parameter specifies the type of tunnel used between an RSIP host and an RSIP gateway. Defined tunnel types are:
Tunnel Type
-----------
0 Reserved
1 IP-IP
2 GRE
3 L2TP8.7. RSIP Method 🎬
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length = 1 | RSIP method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the RSIP method parameter specifies an RSIP method. Defined RSIP methods are:
RSIP method
-----------
0 Reserved
1 RSA-IP
2 RSAP-IP8.8. Error 🚨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 | Length = 2 | Error |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error |
+-+-+-+-+-+-+-+-+the error parameter specifies an error. The currently defined error values are presented in Appendix A 📋
8.9. Flow Policy 🌊
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length = 2 | Local |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote |
+-+-+-+-+-+-+-+-+the flow policy parameter specifies both the local and remote flow policy 💁♀️
Defined local flow policies are:
Local Flow Policy
-----------------
0 Reserved
1 Macro flows
2 Micro flowsDefined remote flow policies are:
Remote Flow Policy
------------------
0 Reserved
1 Macro flows
2 Micro flows
3 No policy8.10. Indicator 🚩
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 | Length = 2 | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+an indicator parameter is a general-purpose parameter, and how it gets used is defined by the message it shows up in 🎯 an RSIP message that uses an indicator parameter MUST define the meaning and interpretation of all of the indicator's possible values.
8.11. Message Counter 🔢
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Length = 4 | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+a message counter parameter is used to mark RSIP messages with sequentially-increasing values ➕ Message counters MUST be used with UDP, in order to facilitate reliability.
8.12. Vendor Specific Parameter 🏷️
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 12 | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | Subtype | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the vendor specific parameter is used to encode parameters that are defined by a particular vendor 🏢 the vendor ID field is the vendor-specific ID assigned by IANA. Subtypes are defined and used by each vendor as necessary. An RSIP host or gateway SHOULD silently ignore vendor-specific messages that it does not understand 🙉
9. Message Types ✨
okay bestie, so every RSIP message starts with three mandatory fields: version, message type, and overall length. After those come one or more required parameters, in a fixed order, and then zero or more optional parameters 💖 The required parameters MUST show up in the exact order listed in the spec, but the optional ones MAY appear in any order 🎀 Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message type | Overall length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameters...
+-+-+-+-+-+-+-+-+-+-+The version field is one byte and tells you which RSIP version is in use. The current version is 1 🦋
The message type field is also one byte and says which message is inside the packet. Only one message fits in each packet, no doubles 🙅♀️ You'll find the numerical assignments for message types in Appendix B 🌸
The overall length field is two bytes and counts every byte in the RSIP message, the three mandatory fields included ✨
Most parameters can only show up once per message, but there are a few exceptions, and they're giving main character energy 👑
- Multiple address parameters MUST appear in
ASSIGN_REQUEST_RSA-IP,ASSIGN_RESPONSE_RSA-IP,ASSIGN_REQUEST_RSAP-IP,ASSIGN_RESPONSE_RSAP-IP,LISTEN_REQUESTandLISTEN_RESPONSE. - Multiple ports parameters MUST appear in
ASSIGN_REQUEST_RSAP-IP,ASSIGN_RESPONSE_RSAP-IP,LISTEN_REQUESTandLISTEN_RESPONSE. - Multiple RSIP method and tunnel type parameters MAY appear in
RESISTER_RESPONSE. - Multiple address parameters and multiple indicator parameters MAY appear in
QUERY_REQUESTandQUERY_RESPONSE.
The message types are defined in BNF 🧁 Required parameters sit inside <> and MUST appear. Optional parameters sit inside [] and MAY appear. You don't have to implement every message type to be RSIP compliant 💅 For example, an RSIP host and/or gateway might skip LISTEN_REQUEST and LISTEN_RESPONSE, or only support RSAP-IP and not RSA-IP. Totally valid, no cap 🫶
9.1. ERROR_RESPONSE
9.1.1. Description
An ERROR_RESPONSE is how an RSIP gateway tells an RSIP host that something went wrong 😭 Usually it means the gateway can't or won't do the thing, or give out resources, on the host's behalf. If the error is tied to a particular client ID or bind ID, those associated parameters MUST be included 🔥 Only one error can be reported per ERROR_RESPONSE, so multiple errors MAY NOT be reported together. If more than one error happened, the RSIP gateway MUST pick just one to report 💖
9.1.2. Format
<ERROR_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Error>
[Message Counter]
[Client ID]
[Bind ID]9.1.3. Behavior
An ERROR_RESPONSE message MUST only be sent by an RSIP gateway 🙅♀️ If an RSIP host spots an error in a message from a gateway, it MUST silently discard that message 🤫 An ERROR_RESPONSE can't cause any error conditions of its own, so no error spirals here ✨ It's usually sent in reply to a request from an RSIP host, but a gateway can also send one on its own, out of nowhere 🧚
9.2. REGISTER_REQUEST
9.2.1. Description
The REGISTER_REQUEST message is how an RSIP host registers with an RSIP gateway 🎀 A host MUST register before it asks the gateway for resources or services, no skipping the intro 💅 And once a host is registered, it may not register again until it has de-registered from that gateway. One registration at a time, bestie 🌈
9.2.2. Format
<REGISTER_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
[Message Counter]9.2.3. Behavior
These are the message-specific error conditions:
- If the host is already registered with the gateway, the gateway MUST respond with an
ERROR_RESPONSEcontaining theALREADY_REGISTEREDerror and the RSIP host's client ID. 🙄 - If the gateway's policy won't let the host register, the gateway MUST respond with an
ERROR_RESPONSEcontaining theREGISTRATION_DENIEDerror. 💀
9.3. REGISTER_RESPONSE
9.3.1. Description
The REGISTER_RESPONSE message is how an RSIP gateway confirms a host's registration ✨ It also hands over a client ID, a flow policy, and maybe a message counter plus one or more RSIP methods and/or tunnel types. Very generous of them 🥹
9.3.2. Format
<REGISTER_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Lease time>
<Flow Policy>
[Message Counter]
[RSIP Method]...
[Tunnel Type]...9.3.3. Behavior
An RSIP gateway MUST give a different client ID to each host that's registered with it at the same time 🧁 The gateway MAY reply with one or more RSIP methods and tunnel types it supports 🌸 If no RSIP method is specified, RSAP-IP MUST be assumed. If no tunnel type is specified, IP-IP MUST be assumed. Default vibes, but make it official 💜
9.4. DE-REGISTER_REQUEST
9.4.1. Description
The DE-REGISTER_REQUEST message is how an RSIP host de-registers from an RSIP gateway 👋 If a host de-registers from the assigned state, all of its bindings get revoked, so the host loses everything it had 😬 The host SHOULD NOT de-register from the unregistered state. Nothing to leave if you were never in the room 🙈
9.4.2. Format
<DE-REGISTER_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Message Counter]9.4.3. Behavior
These are the message-specific error conditions:
- If the host isn't registered with the gateway, the gateway MUST respond with an
ERROR_RESPONSEcontaining theREGISTER_FIRSTerror. 🙃 - If the message has an incorrect client ID, the gateway MUST respond with an
ERROR_RESPONSEcontaining theBAD_CLIENT_IDerror. 🚫
If nothing goes wrong with this message, the gateway MUST respond with a proper DE-REGISTER_RESPONSE. When a host de-registers, the RSIP gateway has to delete all binds tied to that host and return their resources to the pool of free resources 🧹 Once a host has de-registered, it can't use any of the gateway's resources again unless it registers again. Fresh start, bestie ✨
9.5. DE-REGISTER_RESPONSE
9.5.1. Description
The DE-REGISTER_RESPONSE message is how an RSIP gateway confirms a host's de-registration, or forces the host to give up all its bindings and end its relationship with the gateway 💅 When a host gets a DE-REGISTER_RESPONSE, it MUST stop using every resource the gateway allocated to it. Immediately. No exceptions 😤
9.5.2. Format
<DE-REGISTER_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Message Counter]9.5.3. Behavior
An RSIP gateway MUST send a DE-REGISTER_RESPONSE in reply to a valid DE-REGISTER_REQUEST 🫶 It also MUST send a DE-REGISTER_RESPONSE to an RSIP host when that host's registration lease time runs out ⏰ An RSIP gateway SHOULD send a DE-REGISTER_RESPONSE if it notices it won't be able to do RSIP stuff for a given host anymore. An RSIP host MUST be ready to receive a DE-REGISTER_RESPONSE at any moment, so stay alert, bestie 👀
9.6. ASSIGN_REQUEST_RSA-IP
9.6.1. Description
The ASSIGN_REQUEST_RSA-IP message is how an RSIP host asks for resources to use with RSA-IP 🦋 Heads up: RSA-IP can't be combined with micro-flow based local policy. Not compatible, sorry not sorry 🙅♀️
9.6.2. Format
<ASSIGN_REQUEST_RSA-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Address (remote)>
<Ports (remote)>
[Message Counter]
[Lease Time]
[Tunnel Type]9.6.3. Behavior 🎀
okay so the RSIP host gets to ask for two address parameters 💅 If it has a favourite local address, it can drop that into the first address parameter ✨ If it's chill and has no preference, it can put a "don't care" value in there instead 🌸
If macro-flow based remote policy is used, the host MUST specify the remote address it'll use this binding (if granted) to contact 🦋 The remote port number MAY stay unspecified. If micro-flow based remote policy is used, the host MUST specify the remote address and port number it'll use this binding (if granted) to contact 💜 And if there's no flow policy at all, the RSIP host can put "don't care" values in the value fields of the respective address and ports parameters 🧚
Here are the message-specific error conditions 🙈
- If the host is not registered with the gateway, the gateway MUST respond with an
ERROR_RESPONSEcontaining theREGISTER_FIRSTerror. - If the message contains an incorrect client ID, the gateway MUST respond with an
ERROR_RESPONSEcontaining theBAD_CLIENT_IDerror. - If the local address parameter is a don't care value and the RSIP gateway cannot allocate ANY addresses, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theLOCAL_ADDR_UNAVAILABLEerror. - If the local address parameter is not a don't care value, there are three possible error conditions:
- If the RSIP gateway cannot allocate ANY addresses, it MUST respond with an
ERROR_RESPONSEcontaining theLOCAL_ADDR_UNAVAILABLEerror. - If the RSIP gateway cannot allocate the requested address because it is in use, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theLOCAL_ADDR_INUSEerror. - If the RSIP gateway cannot allocate the requested address because it is not allowed by policy, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theLOCAL_ADDR_UNALLOWEDerror.
- If the RSIP gateway cannot allocate ANY addresses, it MUST respond with an
- If macro-flow based remote policy is used and the requested remote address is not allowed by the RSIP gateway's policy, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theREMOTE_ADDR_UNALLOWEDerror. - If micro-flow based remote policy is used and the requested remote address / port pair is not allowed by the RSIP gateway's policy, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theREMOTE_ADDRPORT_UNALLOWEDerror. - If an unsupported or unallowed tunnel type is specified, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theBAD_TUNNEL_TYPEerror. - If the host has not specified local or remote address or port information in enough detail, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theFLOW_POLICY_VIOLATIONerror.
9.7. ASSIGN_RESPONSE_RSA-IP
9.7.1. Description
The ASSIGN_RESPONSE_RSA-IP message is how an RSIP gateway hands out parameter assignments to an RSIP host using RSA-IP 🌈 Every assignment needs a host-wise unique bind ID, a lease time, and a tunnel type, no exceptions 💅
9.7.2. Format
<ASSIGN_RESPONSE_RSA-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Address (remote)>
<Ports (remote)>
<Lease Time>
<Tunnel Type>
[Address (tunnel endpoint)]
[Message Counter]9.7.3. Behavior
If no remote flow policy is used, the RSIP gateway MUST use "don't care" values for the remote address and ports parameters 🫶 If macro-flow based remote policy is used, the remote address parameter MUST contain the address from the associated request, and the remote ports parameter MUST contain a "don't care" value 🦋 If micro-flow based remote policy is used, the remote address and remote ports parameters MUST contain the address and port information from the associated request ✨
If the host detects an error or otherwise doesn't "understand" the gateway's response, it SHOULD send a FREE_REQUEST with the bind ID from the said ASSIGN_RESPONSE_RSA-IP 🙈 This helps the host and gateway sync their states back up 💖
The address of a tunnel endpoint that isn't the RSIP gateway MAY be specified. If this parameter isn't specified, the RSIP gateway MUST be assumed to be the tunnel endpoint 🧚
9.8. ASSIGN_REQUEST_RSAP-IP
9.8.1. Description
The ASSIGN_REQUEST_RSAP-IP message is how an RSIP host asks for resources to use with RSAP-IP 🌸 The host gives two address parameters and two port parameters. The first of each refers to the local address and port(s) that will be used, and the second of each refers to the remote address and port(s) that will be contacted 💅
9.8.2. Format
<ASSIGN_REQUEST_RSAP-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
[Message Counter]
[Lease Time]
[Tunnel Type]9.8.3. Behavior
An RSIP host can ask for a particular local address by putting it in the value field of the first address parameter 👑 It can ask for particular local ports by putting them in the first port parameter 🍓 If it has no preference, it can put a "don't care" value in the respective address or ports parameters 🌈
If macro-flow based remote policy is used, the host MUST specify the remote address it'll use this binding (if granted) to contact 🦋 The remote port number(s) MAY stay unspecified. If micro-flow based remote policy is used, the host MUST specify the remote address and port number(s) it'll use this binding (if granted) to contact 💜 If no flow policy is used, the RSIP host can put a value of all 0's in the value fields of the respective address or port parameters 🧚
Here are the message-specific error conditions 🙈
- If the host is not registered with the gateway, the gateway MUST respond with an
ERROR_RESPONSEcontaining theREGISTER_FIRSTerror. - If the message contains an incorrect client ID, the gateway MUST respond with an
ERROR_RESPONSEcontaining theBAD_CLIENT_IDerror. - If the local address parameter is a don't care value and the RSIP gateway cannot allocate ANY addresses, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theLOCAL_ADDR_UNAVAILABLEerror. - If the local address parameter is not a don't care value, there are five possible error conditions:
- If the RSIP gateway cannot allocate ANY addresses, it MUST respond with an
ERROR_RESPONSEcontaining theLOCAL_ADDR_UNAVAILABLEerror. - If the RSIP gateway cannot allocate the requested address because it is in use, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theLOCAL_ADDR_INUSEerror. - If the RSIP gateway cannot allocate the requested address because it is not allowed by policy, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theLOCAL_ADDR_UNALLOWEDerror. - If the RSIP gateway cannot allocate a requested address / port tuple because it is in use, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theLOCAL_ADDRPORT_INUSEerror. - If the RSIP gateway cannot allocate a requested address / port tuple because it is not allowed by policy, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theLOCAL_ADDRPORT_UNALLOWEDerror.
- If the RSIP gateway cannot allocate ANY addresses, it MUST respond with an
- If the RSIP host requests a number of ports (greater that one) but doesn't specify particular port numbers (i.e., uses "don't care" values) and the RSIP gateway can't grant the entire request, the RSIP gateway MUST return an
ERROR_RESPONSEcontaining theLOCAL_ADDRPORT_UNAVAILABLEerror. - If macro-flow based remote policy is used and the requested remote address is not allowed by the RSIP gateway's policy, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theREMOTE_ADDR_UNALLOWEDerror. - If micro-flow based remote policy is used and the requested remote address / port pair is not allowed by the RSIP gateway's policy, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theREMOTE_ADDRPORT_UNALLOWEDerror. - If an unsupported or unallowed tunnel type is specified, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theBAD_TUNNEL_TYPEerror. - If the host hasn't specified local or remote address or port information in enough detail, the RSIP gateway MUST respond with an
ERROR_RESPONSEcontaining theFLOW_POLICY_VIOLATIONerror.
9.9. ASSIGN_RESPONSE_RSAP-IP
9.9.1. Description
The ASSIGN_RESPONSE_RSAP-IP message is how an RSIP gateway delivers parameter assignments to an RSIP host ✨ Every assignment needs a host-wise unique bind ID, a lease time, and a tunnel type 🎀
9.9.2. Format
<ASSIGN_RESPONSE_RSAP-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<Lease Time>
<Tunnel Type>
[Address (tunnel endpoint)]
[Message Counter]9.9.3. Behavior 🎀
Okay so no matter what local flow policy is in play, the host MUST get a local address and port(s) assigned to it 💖 If macro-flow based local policy is used, the host gets an address and one or more ports ✨ If micro-flow based local policy is used, the host gets an address and exactly one port 🦋
If no remote flow policy is used, the RSIP gateway MUST use "don't care" values for the remote address and ports parameters 🌸 If macro-flow based remote policy is used, the remote address parameter MUST contain the address specified in the associated request, and the remote ports parameter must contain a "don't care" value 🍓 If micro-flow based remote policy is used, the remote address and remote ports parameters MUST contain the address and port information specified in the associated request 💅
If the host detects an error or otherwise does not "understand" the gateway's response, it SHOULD send a FREE_REQUEST with the bind ID from the said ASSIGN_RESPONSE_RSAP-IP. This will serve to help synchronize the states of the host and gateway 🫶
The address of a tunnel endpoint that is not the RSIP gateway MAY be specified. If this parameter is not specified, the RSIP gateway MUST be assumed to be the tunnel endpoint 🧚
9.10. EXTEND_REQUEST 🌈
9.10.1. Description
The EXTEND_REQUEST message is used to request a lease extension to a current bind. It may be used with both RSA-IP and RSAP-IP. The host MUST specify its client ID and the bind ID in question, and it MAY suggest a lease time to the gateway 💜
9.10.2. Format
<EXTEND_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
[Lease Time]
[Message Counter]9.10.3. Behavior 🧚
The following message-specific error conditions exist:
- If the host is not registered with the gateway, the gateway MUST respond with an
ERROR_RESPONSEcontaining theREGISTER_FIRSTerror. 🙈 - If the message contains an incorrect client ID, the gateway MUST respond with an
ERROR_RESPONSEcontaining theBAD_CLIENT_IDerror. 💀 - If the message contains an incorrect bind ID, the gateway MUST respond with an
ERROR_RESPONSEcontaining theBAD_BIND_IDerror. 😭
If the RSIP gateway grants an extension to the host's lease, it MUST RESPOND with an appropriate EXTEND_RESPONSE message. If the lease is not renewed, the RSIP gateway MAY let it implicitly expire by doing nothing, or make it explicitly expire by sending an appropriate FREE_RESPONSE message 🦋
9.11. EXTEND_RESPONSE ✨
9.11.1. Description
The EXTEND_RESPONSE message is used by an RSIP gateway to grant a requested lease extension. The gateway MUST specify the client ID of the host, the bind ID in question, and the new assigned lease time 🎀
9.11.2. Format
<EXTEND_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Lease Time>
[Message Counter]9.11.3. Behavior 🌸
The RSIP gateway will determine lease time as per its local policy. The returned time is to be interpreted as the number of seconds before the lease expires, counting from the time at which the message is sent/received ⭐
9.12. FREE_REQUEST 🍓
9.12.1. Description
The FREE_REQUEST message is used by an RSIP host to free a binding. The given bind ID identifies the bind to be freed. Resources may only be freed using the granularity of a bind ID 🫶
9.12.2. Format
<FREE_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
[Message Counter]9.12.3. Behavior 💅
The following message-specific error conditions exist:
- If the host is not registered with the gateway, the gateway MUST respond with an
ERROR_RESPONSEcontaining theREGISTER_FIRSTerror. 🙈 - If the message contains an incorrect client ID, the gateway MUST respond with an
ERROR_RESPONSEcontaining theBAD_CLIENT_IDerror. 💀 - If the message contains an incorrect bind ID, the gateway MUST respond with an
ERROR_RESPONSEcontaining theBAD_BIND_IDerror. 😭
If a host gets an error back in response to a FREE_REQUEST, that might mean the host and gateway's states have gone out of sync 😬 So the host SHOULD make an effort to resynchronize, like freeing resources and then re-requesting them, or de-registering and then re-registering. Iykyk 🔥
9.13. FREE_RESPONSE 🧚
9.13.1. Description
The FREE_RESPONSE message is used by an RSIP gateway to acknowledge a FREE_REQUEST sent by an RSIP host, and to asynchronously deallocate resources granted to an RSIP host 🦋
9.13.2. Format
<FREE_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
[Message Counter]9.13.3. Behavior 🌈
An RSIP host must always be ready to accept a FREE_RESPONSE, even if its lease on the specified bind ID is not yet expired 👑
9.14. QUERY_REQUEST 💜
9.14.1. Description
A QUERY_REQUEST message is used by an RSIP host to ask an RSIP gateway whether or not a particular address or network is local or remote. The host uses this information to determine whether to contact the host(s) directly (in the local case), or via RSIP (in the remote case) 🌸
This message defines an indicator parameter with a 1-byte value field and 2 defined values:
- 1 address
- 2 network
9.14.2. Format
<QUERY_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Message Counter]
[Address Tuple]...
[Network Tuple]...
where
<Address Tuple> ::= <Indicator (address)>
<Address>
<Network Tuple> ::= <Indicator (network)>
<Address (network)>
<Address (netmask)>9.14.3. Behavior ✨
One or more address or network tuples may be specified. Each tuple encodes a request regarding the locality (local or remote) of the encoded address or network. If no tuple is specified, the RSIP gateway should interpret the message as a request for all tuples that it is willing to provide. Note that the FQDN form of the address parameter cannot be used to specify the address of a network, and only the netmask form of the address parameter can be used to specify the netmask of a network 🍓
If an RSIP gateway cannot determine whether a queried host or network is local or remote, it SHOULD transmit a QUERY_RESPONSE with no response specified for the said host or network 🫶
The following message-specific error conditions exist:
- If the host is not registered with the gateway, the gateway MUST respond with an
ERROR_RESPONSEcontaining theREGISTER_FIRSTerror. 🙈 - If the message contains an incorrect client ID, the gateway MUST respond with an
ERROR_RESPONSEcontaining theBAD_CLIENT_IDerror. 💀
9.15. QUERY_RESPONSE 🎀
9.15.1. Description
A QUERY_RESPONSE message is used by an RSIP gateway to answer a QUERY_REQUEST from an RSIP host 💅
This message defines an indicator parameter with a 1-byte value field and 4 defined values:
- 1 local address
- 2 local network
- 3 remote address
- 4 remote network
9.15.2. Format
<QUERY_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Message Counter]
[Local Address Tuple]...
[Local Network Tuple]...
[Remote Address Tuple]...
[Remote Network Tuple]...
where
<Local Address Tuple> ::= <Indicator (local address)>
<Address>
<Local Network Tuple> ::= <Indicator (local network)>
<Address (network)>
<Address (netmask)>
<Remote Address Tuple> ::= <Indicator (remote address)>
<Address>
<Remote Network Tuple> ::= <Indicator (remote network)>
<Address (network)>
<Address (netmask)>9.15.3. Behavior 🧚
An RSIP gateway has some leeway in how it responds to a QUERY_REQUEST. It may just provide the information requested, if it can provide such information. It may provide its complete list of address and networks, in order to minimize the number of requests that the host needs to perform in the future. How an RSIP gateway responds may depend on network traffic considerations as well 🌈
If an RSIP gateway sends a QUERY_RESPONSE that does not contain any tuples, or a QUERY_RESPONSE that does not contain a tuple that applies to an associated tuple in the associated QUERY_REQUEST, this should be interpreted that the RSIP gateway does not know whether the queried host or network is local or remote. Appropriate host behavior upon receipt of such a message is to assume that the queried host or network is remote 👑
Note that an RSIP gateway is not expected to maintain a complete list of all remote hosts and networks. In fact, a typical RSIP gateway will only maintain a list of the networks and hosts that it knows are local (private with respect to the RSIP host) 🦋
9.16. LISTEN_REQUEST 🌸
9.16.1. Description
A LISTEN_REQUEST message is sent by an RSIP host that wants to register a service on a particular address and port number. The host must include its client ID, local address parameter and ports parameters, and remote address and ports parameters. The client MAY suggest a lease time and one or more tunnel types 🍓
9.16.2. Format
<LISTEN_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
[Message Counter]
[Lease Time]
[Tunnel Type]...9.16.3. Behavior 🎀
okay so if the host wants to listen on a specific address or port, it may specify these in the address and ports parameters. otherwise it can leave one or both of them as "don't care" values 🫶
if no remote flow policy is being used, the host MUST fill both the remote address and ports parameters with "don't care" values 💅 if macro-flow based remote policy is used, the host MUST specify the remote address, but MAY or MAY NOT specify the remote port(s) 🦋 and if micro-flow based remote policy is used, the host MUST specify the remote address and ports parameter 🔥
once a LISTEN_REQUEST has been granted, the RSIP gateway MUST forward all packets destined to the address and port in question to the host 💖 even if that remote host address and port tuple has never been contacted by the host before. literally iconic ✨
LISTEN_REQUEST is not necessary for RSA-IP 🌸
now the error situations, which are giving very specific vibes 😭
- if the host is not registered with the gateway, the gateway MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRSTerror 💀 - if the message contains an incorrect client ID, the gateway MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_IDerror 🙈 - if the local address parameter is a don't care value and the RSIP gateway cannot allocate ANY addresses, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLEerror 🍓 - if the local address parameter is not a don't care value, there are five possible error conditions, and yes they are all different 🌈
- if the RSIP gateway cannot allocate ANY addresses, it MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLEerror 💜 - if the RSIP gateway cannot allocate the requested address because it is in use, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_INUSEerror 🧚 - if the RSIP gateway cannot allocate the requested address because it is not allowed by policy, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNALLOWEDerror 🌸 - if the RSIP gateway cannot allocate the requested address / port tuple because it is in use, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDRPORT_INUSEerror ✨ - if the RSIP gateway cannot allocate the requested address / port tuple because it is not allowed by policy, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDRPORT_UNALLOWEDerror 🫶
- if the RSIP gateway cannot allocate ANY addresses, it MUST respond with an ERROR_RESPONSE containing the
- if macro-flow based remote policy is used and the requested remote address is not allowed by the RSIP gateway's policy, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the
REMOTE_ADDR_UNALLOWEDerror 🔥 - if micro-flow based remote policy is used and the requested remote address / port pair is not allowed by the RSIP gateway's policy, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the
REMOTE_ADDRPORT_UNALLOWEDerror 👑 - if an unsupported or unallowed tunnel type is specified, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the
BAD_TUNNEL_TYPEerror 🦋 - if the host has not specified local or remote address or port information in enough detail, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the
FLOW_POLICY_VIOLATIONerror 💅
9.17. LISTEN_RESPONSE 🌈
9.17.1. Description ✨
a LISTEN_RESPONSE message is how an RSIP gateway answers a LISTEN_REQUEST from an RSIP host 💖 the RSIP gateway MUST issue a bind ID, and specify the address and port that have been granted to the host. the gateway must also specify a tunnel type and lease time 🎀
if no remote flow policy is being used, the gateway MUST fill both the remote address and ports parameters with "don't care" values 🫶 if macro-flow based remote policy is used, the gateway MUST specify the remote address, but MAY or MAY NOT specify the remote port(s) 🦋 and if micro-flow based remote policy is used, the gateway MUST specify the remote address and ports parameter 🔥
9.17.2. Format 🧚
<LISTEN_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<Tunnel Type>
<Lease Time>
[Address (tunnel endpoint)]
[Message Counter]9.17.3. Behavior 💜
same rule as before, bestie 💅 if no remote flow policy is being used, the gateway MUST fill both the remote address and ports parameters with "don't care" values. if macro-flow based remote policy is used, the gateway MUST specify the remote address, but MAY or MAY NOT specify the remote port(s). and if micro-flow based remote policy is used, the gateway MUST specify the remote address and ports parameter 👑
the address of a tunnel endpoint that is not the RSIP gateway MAY be specified 🌸 if this parameter is not specified, the RSIP gateway MUST be assumed to be the tunnel endpoint ✨
10. Discussion 🍓
10.1. Use of Message Counters, Timeouts, and Retransmissions ⏰
message counters are basically sequence numbers' cool cousin 🦋 they're needed for reliability when UDP is the transport protocol. every UDP message gets marked with a message counter. when one is sent, a copy goes into a "last message" buffer, and for RSIP hosts a timer is set to expire at the appropriate timeout value 🫶
general rules, no cap:
- when an RSIP host transmits a message with a message counter value of n, the RSIP gateway's response will contain a message counter value of n 💖
- an RSIP host will not increment its message counter value to n+1 until it receives a message from the RSIP gateway with a message counter value of n 🎀
- an RSIP gateway begins all sessions with a message counter value of 1 🌈
- if the message counter value reaches the maximum possible 32-bit value, it will wrap around to 1, not 0 🧚
- if a message with a message counter value of n is transmitted by an RSIP host, but a timer expires before a response to that message is received, the copy of the message (from the "last message" buffer) is retransmitted 🔥
- when an RSIP gateway receives a duplicate copy of a message with a message counter value of n, it transmits the contents of its "last message" buffer 🙈
- when the RSIP gateway transmits an asynchronous RSIP message (an RSIP message for which there was no request by the RSIP host), a message counter value of 0 MUST be used. note that only three RSIP messages can be transmitted asynchronously: ERROR_RESPONSE, DE-REGISTER_RESPONSE, and FREE_RESPONSE. these messages may also be transmitted in response to an RSIP host request, so their message counter values MAY be non-zero 💅
- if a message counter is not present in a message from an RSIP host, but is required, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the
MESSAGE_COUNTER_REQUIREDerror 💀
10.2. RSIP Host and Gateway Failure Scenarios 💥
when either the RSIP host or the gateway suffers an unrecoverable failure, like a crash, all RSIP-related state is lost 😭 this section walks through what happens in host and gateway failures, and how the host and gateway re-synchronize 🫶
10.2.1. Host Failure 🌸
after a host failure, the host reboots and has no idea about any RSIP state the gateway is holding on its behalf 🙈
if the host doesn't immediately try to re-establish a session, it may receive RSIP packets on the RSIP client application port it was using before the reboot. if no RSIP client application is active on this port, those packets get answered with ICMP port unreachable messages. if TCP is the transport protocol, the connection will probably be terminated with a TCP RST. if an RSIP client is active on this port, it won't recognize the session these packets belong to, and it SHOULD silently ignore them 🧚
the RSIP host may also receive packets from a remote host it was talking to before the reboot 🦋 these packets will be destined to the RSIP tunnel interface, which should not exist. so they SHOULD be silently discarded by the RSIP host's stack, or the RSIP host will transmit appropriate ICMP messages to the tunnel endpoint (e.g., the RSIP gateway). the behavior of the system with respect to sessions that were active before the reboot should be similar to that of a publically addressable non-RSIP host that reboots 👑
upon rebooting, an RSIP host may try to establish a new RSIP session with the RSIP gateway 💖 when the gateway gets the REGISTER_REQUEST message, it can tell that, as far as it's concerned, the RSIP host is already registered. so it will transmit an ERROR_RESPONSE with the ALREADY_REGISTERED message 🎀 once the host gets that, it knows the client ID of its old registration, and it SHOULD immediately transmit a DE-REGISTER_REQUEST using this client ID 🔥 after that's done, the states of the RSIP host and gateway are synchronized, and a new RSIP session may be established ✨
if the RSIP host doesn't de-register itself from the RSIP gateway, it will eventually receive a DE-REGISTER_RESPONSE from the gateway when the gateway times out the host's session 🌈 since that DE-REGISTER_RESPONSE refers to a client ID that means nothing to the host, the host SHOULD silently ignore such a message 🙈 at this point, the states of the RSIP host and gateway are synchronized, and a new RSIP session may be established 🫶
10.2.2. Gateway Failure
okay so if the gateway crashes, it reboots and has zero memory of any RSIP state its hosts are holding 💀
Since the gateway never goes looking for its RSIP hosts, the problem shows up in one of three ways: an RSIP host sends an RSIP message to the gateway, an RSIP host sends tunneled data to the gateway, or data from a remote host meant for an RSIP host shows up at the gateway. 🙈
In the first case, the RSIP gateway SHOULD immediately respond to all messages (except for a REGISTER_REQUEST) with an ERROR_RESPONSE that carries a REGISTER_FIRST error. 🚨 When a host gets that message, it MUST treat it as a sign that it and the gateway have lost sync. The host SHOULD immediately send a DE-REGISTRATION_REQUEST using its old client ID. That'll trigger another error, but the host SHOULD ignore that second error 🙄 Once that's done, the host and gateway states are back in sync, and a new RSIP session may be set up. ✨
In the second case, anything the host sends into the tunneled interface of an RSIP server will either (1) get dropped silently, (2) get an ICMP Destination Unreachable message back, like "Communication Administratively Prohibited", or (3) get blindly routed to wherever it was headed. In every one of these cases the gateway has no clean way to tell the host something went wrong, which is lowkey rough 😭 To stop this from turning into a long outage, the RSIP gateway can set small lease times of several minutes. 🫶
In the third case, the RSIP gateway SHOULD discard all incoming packets and/or respond with ICMP Port Unreachable messages. 🌸
10.3. General Gateway Policy
There's a whole lot of RSIP gateway policy that could be put in place, but it's out of scope for this doc 💅 We expect most of it to be site-specific or implementation-specific, so we don't make any recommendations here. Examples of general gateway policy include:
- How ports are allocated to RSIP hosts.
- Preferred length of lease times.
- How flow policy is applied to which hosts.
- How an RSIP gateway with multiple public IP addresses that may be leased by RSIP clients determines how to partition and/or lease these addresses.
10.4. Errors Not From the RSIP Protocol
Once an RSIP host and gateway have a relationship going and the host has been given resources to use, errors can still happen 😤 Maybe the host is misusing what it got, or it's trying to use stuff that was never assigned to it. These are the error behaviors that are defined:
- If a host attempts to use a local address that it has not been allocated, the RSIP gateway MUST drop the associated packet(s) and send the host an ERROR_RESPONSE containing the
LOCAL_ADDR_UNALLOWEDerror. 🛑 - If a host attempts to use a local address / port tuple that it has not been allocated, the RSIP gateway MUST drop the associated packet(s) and send the host an ERROR_RESPONSE containing the
LOCAL_ADDRPORT_UNALLOWEDerror. 🛑 - If a host attempts to contact a remote address that has not been properly specified or otherwise approved (e.g., via an ASSIGN_RESPONSE_RSAP-IP and macro or micro based remote flow policy), the RSIP gateway MUST drop the associated packet(s) and send the host an ERROR_RESPONSE containing the
REMOTE_ADDR_UNALLOWEDerror. 🛑 - If a host attempts to contact a remote address / port tuple that has not been properly specified or otherwise approved (e.g., via an ASSIGN_RESPONSE_RSAP-IP and micro based remote flow policy), the RSIP gateway MUST drop the associated packet(s) and send the host an ERROR_RESPONSE containing the
REMOTE_ADDRPORT_UNALLOWEDerror. 🛑 - If a host attempts to establish or use an improper tunnel type, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the
BAD_TUNNEL_TYPEerror. 🚫 - If the RSIP gateway detects a local fault that prevents its RSIP server module from continuing operation, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the
INTERNAL_SERVER_ERRORerror. 😱
10.5. Address and Port Requests and Allocation
No matter what the local flow policy says, an RSIP host may "suggest" the local address and/or port number it would like to use in a particular binding 🦋 If the RSIP gateway can't grant that request because the resources are already in use, it MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_INUSE or LOCAL_ADDRPORT_INUSE values. 🙅♀️
10.6. Local Gateways and Flow Policy Interaction
An RSIP host can set up a publicly accessible gateway (like an FTP or HTTP gateway) by sending a LISTEN_REQUEST message to an RSIP gateway and getting a LISTEN_RESPONSE back 🎀 But unless no remote flow policy is in use, the gateway has to name a single remote host, by address or by address and port, that's allowed to contact it. Honestly, that kind of restriction isn't very useful for hosts that need their gateways reachable by any remote host 🥺
So yeah, there's a real conflict between flow-based policy and gateway support 😬 The main reason for enforcing flow-based policy on LISTEN_REQUESTs is that it gives an RSIP gateway tight control over how an RSIP host uses ports and how that usage gets accounted for. For example, an RSIP host running under remote micro-flow based policy that's using a protocol like FTP will have to specify, in a LISTEN_REQUEST, the address and port it will receive FTP data on, as well as the address and port the gateway will send data from. 📦
In general, an RSIP gateway may not allow arbitrary hosts to start public gateways, because of traffic and security concerns. ⚠️ So we recommend that, if remote micro-flow based policy is used, the RSIP gateway only allows public gateways on RSIP hosts through administrative override. 👑
Right now, RSIP hosts can only be identified by their local IP address or MAC address. 🪪
11. Security Considerations
Okay, real talk: RSIP, all on its own, does not provide security. 💀 It might give you the illusion of security or privacy by hiding a private address space, but actual security only comes from using proper security protocols and cryptographic techniques 🔐
An RSIP gateway should take all measures it deems necessary to stop its hosts from launching intentional or unintentional denial-of-service attacks by requesting large sets of resources. 🛡️
Right now, RSIP hosts can only be identified by their local IP address or, in some cases, their MAC address. It's desirable to let RSIP messages sent between a host and gateway be authenticated 🫶 You can find more on that authentication in [RSIP-FRAME].
Discussion of RSIP support for end-to-end IPsec can be found in [RSIP-IPSEC]. 🧚
12. IANA Considerations
All of the designations below have been registered by the IANA ✨
- RSIP port number: 4555
- RSIP error codes (see Appendix A).
- RSIP message type codes (see Appendix B).
- RSIP tunnel types, methods, and flow policies.
RSIP parameter values are designated as follows:
0 Reserved
1-240 Assigned by IANA
241-255 Reserved for private useNew registrations for the above namespaces are recommended to be allocated via the Specification Required method documented in [RFC2434]. 📝
13. Acknowledgements
The authors would like to give a special shoutout to Gabriel Montenegro, Pyda Srisuresh, Brian Carpenter, Eliot Lear, Dan Nessett, Gary Jaszewski, Naveen Rajanikantha, Sudhakar Ramakrishna, Jim March, and Rick Cobb for their input 🌈 The IETF NAT working group as a whole has been extremely helpful in the ongoing development of RSIP. 👏💖
14. Appendix A: RSIP Error Numbers 🎀
okay so this section is basically the error decoder ring 💅 It goes through every value that can show up in the RSIP error parameter, so you always know what went wrong 🔍
Every error lands in one of four buckets:
100's: General errors. 🌸
101: UNKNOWN_ERROR: an error that can't be identified has happened. This one should be used when all the other error messages are inappropriate 🫶102: USE_TCP: a host tried to use UDP on a server that only supports TCP 🙈103: FLOW_POLICY_VIOLATION: a host hasn't given enough address or port info for its assigned flow policy 💀104: INTERNAL_SERVER_ERROR: an RSIP server application hit an unrecoverable error, either inside itself or inside the RSIP gateway 😭105: MESSAGE_COUNTER_REQUIRED: an RSIP host didn't use a message counter parameter in a spot where it should have 🧚106: UNSUPPORTED_RSIP_VERSION: an RSIP host sent a message with a version number the RSIP gateway doesn't support 🌈
200's: Parameter and message errors. ✨ The gateway uses these when it notices a parameter or message is malformed, and also when it doesn't understand one. 🔥
201: MISSING_PARAM: the request doesn't include a required parameter 👑202: DUPLICATE_PARAM: the request has an illegal duplicate parameter 💅203: EXTRA_PARAM: the request has a parameter it shouldn't have 🍓204: ILLEGAL_PARAM: the gateway doesn't understand a parameter type 🦋205: BAD_PARAM: a parameter is malformed 😭206: ILLEGAL_MESSAGE: the gateway doesn't understand the message type. The message type is neither mandatory nor optional, so it's just not a thing 💀207: BAD_MESSAGE: a message is malformed and the gateway's parsing failed 🙈208: UNSUPPORTED_MESSAGE: the host sent an optional message that the gateway doesn't support 🫶
300's: Permission, resource, and policy errors. 💖 The gateway uses these when a host tries to do something it isn't allowed to do, or something that breaks gateway policy. Main character behavior, but make it a violation 🚫
301: REGISTER_FIRST: the RSIP host tried to request or use resources without registering first 🧚302: ALREADY_REGISTERED: the host tried to register again without de-registering first 🌸303: ALREADY_UNREGISTERED: the host tried to de-register, but it's already in the unregistered state 💜304: REGISTRATION_DENIED: the gateway won't let the host register 🥀305: BAD_CLIENT_ID: the host referred to itself with the wrong client ID 🙈306: BAD_BIND_ID: the request refers to a bind ID that isn't valid for this host 😭307: BAD_TUNNEL_TYPE: the request refers to a tunnel type that isn't valid for this host 🌈308: LOCAL_ADDR_UNAVAILABLE: the gateway can't allocate ANY local address right now, but the host can try again later ⏳309: LOCAL_ADDRPORT_UNAVAILABLE: the gateway can't currently allocate ANY local IP address / port tuple of the requested size (meaning the number of ports), but the host can try again later ⏳310: LOCAL_ADDR_INUSE: the gateway couldn't allocate the requested local address because another entity is using it 🔒311: LOCAL_ADDRPORT_INUSE: the gateway couldn't allocate the requested local address / port tuple because another entity is using it 🔒312: LOCAL_ADDR_UNALLOWED: the gateway won't let the host use the specified local IP address, due to policy 🚫313: LOCAL_ADDRPORT_UNALLOWED: the gateway won't let the host use the specified local address / port pair, due to policy 🚫314: REMOTE_ADDR_UNALLOWED: the gateway won't allow the host to set up a session to the specified remote address 🚫315: REMOTE_ADDRPORT_UNALLOWED: the gateway won't allow the host to set up a session to the specified remote address / port tuple 🚫
400's: IPsec errors. 🔐 These cover every error specific to RSIP / IPsec operation. See [RSIP-IPSEC].
15. Appendix B: Message Types 🦋
this section is the guest list for RSIP message types 💖 It gives the value assigned to each message, says which RSIP entity (host or gateway) produces it, and tells you whether it's mandatory or optional 📋
Quick rule of thumb: all the *_REQUEST messages only get implemented on hosts, and all the *_RESPONSE messages only get implemented on gateways 🧚 And if you want to be "RSIP compliant," every implementation (host and gateway alike) MUST support all the mandatory messages. No skipping the mandatory ones, bestie 🫶
Value Message Implementation Status
------------------------------------------------------------
1 ERROR_RESPONSE gateway mandatory
2 REGISTER_REQUEST host mandatory
3 REGISTER_RESPONSE gateway mandatory
4 DE-REGISTER_REQUEST host mandatory
5 DE-REGISTER_RESPONSE gateway mandatory
6 ASSIGN_REQUEST_RSA-IP host optional
7 ASSIGN_RESPONSE_RSA-IP gateway optional
8 ASSIGN_REQUEST_RSAP-IP host mandatory
9 ASSIGN_RESPONSE_RSAP-IP gateway mandatory
10 EXTEND_REQUEST host mandatory
11 EXTEND_RESPONSE gateway mandatory
12 FREE_REQUEST host mandatory
13 FREE_RESPONSE gateway mandatory
14 QUERY_REQUEST host optional
15 QUERY_RESPONSE gateway mandatory
16 LISTEN_REQUEST host optional
17 LISTEN_RESPONSE gateway optional16. Appendix C: Example RSIP host/gateway transactions 🎀
okay this is the fun one 🍿 It's a walkthrough of a whole RSIP conversation between a host and a gateway, annotated step by step 💬 Host-to-gateway traffic is written as C --> S', and gateway-to-host traffic is written as S --> C. Parameter values sit inside parentheses. Versions, message types, and overall lengths are left out to keep things short. A "don't care" value is shown as 0's 🤷♀️
Ports get their own little shorthand. You write the number of ports, then the port numbers, separated by dashes:
2-1012-1013means two ports, namely 1012 and 1013 🌸16-10000means 16 ports, namely 10000-10015 💜4-0means four ports, but the sender doesn't care which ones 🍓
IPv4 addresses are assumed throughout 🌐
16.1. RSAP-IP with Local Macro-flow Based Policy and No Remote Flow Policy ✨
this example shows the loosest policy setup for RSAP-IP 🦋
C --> S: REGISTER_REQUEST ()The host tries to register with the gateway 🚪
S --> C: REGISTER_RESPONSE (Client ID = 1, Local Flow Policy =
Macro, Remote Flow policy = None, Lease Time = 600)The gateway says yes, gives the host a Client ID of 1, and sets up a local macro-flow based policy with no remote flow policy 🎟️ No RSIP method is indicated, so RSAP-IP is assumed. No tunnel type is indicated either, so IP-IP is assumed. The lease time gets set at 600 seconds ⏱️
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) =
0, Ports (local) = 4-0, Address (remote) = 0, Ports (remote) =
0, Lease Time = 3600)The host asks for an address plus four ports to go with it, but it doesn't care which address or ports it gets 🤷♀️ It doesn't specify a remote address or remote ports either. It suggests a lease time of 3600 seconds 💭
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 1,
Address (local) = 149.112.240.156, Ports (local) = 4-1234,
Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800,
Tunnel Type = IP-IP)The gateway comes back with a bind ID of 1, assigned to IP address 149.112.240.156 with ports 1234-1237 🎉 Any remote host can be communicated with, using any remote port number. The lease time gets set to 1800 seconds, and the tunnel type is confirmed as IP-IP 🥳
The host can now talk to any host on the public network using these resources 🌍✨
C --> S: QUERY_REQUEST: (Client ID = 1, Indicator = network,
Address (network) = 10.20.60.0, Address (netmask)
255.255.255.0)The host asks the gateway whether the network 10.20.60.0/24 is local 🔍
S --> C: QUERY_RESPONSE: (Client ID = 1, Indicator = network,
Address (network) = 10.20.60.0, Address (netmask) =
255.255.255.0)The gateway says yes, that network is local 🏠
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) =
149.112.240.156, Ports (local) = 8-1238, Address (remote) = 0,
Ports (remote) = 0, Lease Time = 1800)The host wants eight more specific ports to use with RSAP-IP, on the same address, with a lease of 1800 seconds 📦 IP-IP tunneling is implied by default 💅
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 2,
Address (local) = 149.112.240.156, Ports (local) = 8-1305,
Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800)The gateway grants the request on the same address, but with a different set of ports 🎀 IP-IP tunneling is implied by default here too.
C --> S: FREE_REQUEST (Client ID = 1, Bind ID = 1)The host frees bind ID 1, which means ports 1234-1237 on IP address 149.112.240.156 🕊️ The address itself stays assigned to the host, because the host still holds ports 1305-1314 🫶
S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 1)The gateway confirms that bind ID 1 has been freed ✅
C --> S: EXTEND_REQUEST (Client ID = 1, Bind ID = 2, Lease Time =
1800)The host asks for the lease on bind ID 2 to be extended for 1800 seconds 🔄
S --> C: EXTEND_RESPONSE (Client ID = 1, Bind ID = 2, Lease Time =
1800)The gateway confirms the extension 💖
S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 2)Plot twist: the gateway forces the host to free the resources of bind ID 2 😭
C --> S: DE-REGISTER_REQUEST (Client ID = 1)The host de-registers with the server 👋
S --> C: DE-REGISTER_RESPONSE (Client ID = 1)The gateway acknowledges that the host has de-registered 🥹💜
16.2. RSAP-IP with Local Micro-flow Based Policy and Remote Micro-flow Based Policy ✨
okay this one is the strictest policy setup for RSAP-IP, so it's giving maximum control 🔒💅
C --> S: REGISTER_REQUEST ()the host tries to register with the gateway 🦋
S --> C: REGISTER_RESPONSE (Client ID = 5, Local Flow Policy =
Micro, Remote Flow policy = Micro, RSIP Method = RSAP-IP, RSIP
Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = GRE, Lease
Time = 600)the gateway says yes and hands out a Client ID of 5, with local micro-flow based policy and remote micro-flow based policy 🎀 both RSAP-IP and RSA-IP are supported, both IP-IP and GRE tunnel types are supported, and the lease time is 600 seconds ⏳
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 5, Address (local) =
0, Ports (local) = 0, Address (remote) = 38.196.73.6, Ports
(remote) = 21, Lease Time = 600, Tunnel Type = IP-IP)the host asks for a local address and a port to go with it 🌸 it wants to talk to host 38.196.73.6 on port 21 (that's FTP control, iykyk) and it asks for a 600 second lease with IP-IP as the tunnel type
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 5, Bind ID = 1,
Address (local) = 149.112.240.156, Ports (local) = 2049,
Address (remote) = 38.196.73.6, Ports (remote) = 21, Lease Time
= 600, Tunnel Type = IP-IP)the gateway comes back with a bind ID of 1, tied to IP address 149.112.240.156 and port 2049 🧚 and only host 38.196.73.6 on port 21 can be contacted, which is so exclusive 👑 the lease is 600 seconds and the tunnel type is confirmed as IP-IP
C --> S: LISTEN_REQUEST: (Client ID = 5, Address (local) =
149.112.240.156, Ports (local) = 2050, Address (remote) =
38.196.73.6, Ports (remote) = 20)the host asks to listen on port 2050 at the address it was just given 🫶 only host 38.196.73.6 coming from port 20 (FTP data) will be able to reach it
S --> C: LISTEN_RESPONSE: (Client ID = 5, Address (local) =
149.112.240.156, Ports (local) = 2050, Address (remote) =
38.196.73.6, Ports (remote) = 20, Lease Time = 600, Tunnel Type
= IP-IP)the gateway confirms it, with a 600 second lease and IP-IP as the tunnel type 💖
C --> S: DE-REGISTER_REQUEST (Client ID = 5)the host de-registers with the server 🌈
S --> C: DE-REGISTER_RESPONSE (Client ID = 5)the gateway acknowledges the de-registration 💅 all of the host's bindings have been implicitly revoked, so everything just disappears on its own ✨
16.3. RSA-IP with Local Macro-flow Based Policy and Remote Macro-flow based Policy 🌷
this one shows a medium level of control for RSA-IP, so it's the middle-of-the-road vibe 🍓
C --> S: REGISTER_REQUEST ()the host tries to register with the gateway 💜
S --> C: REGISTER_RESPONSE (Client ID = 3, Local Flow Policy =
Macro, Remote Flow policy = Macro, RSIP Method = RSAP-IP, RSIP
Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = L2TP, Lease
Time = 600)the gateway gives the host a Client ID of 3, with local macro-flow based policy and remote macro-flow based policy 🦋 both RSAP-IP and RSA-IP are supported, IP-IP and L2TP tunnel types are both supported, and a 600 second lease time is assigned
C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address (local) =
0, Address (remote) = www.foo.com, Ports (remote) = 0, Lease
Time = 3600, Tunnel Type = IP-IP)the host asks for a local address and says it wants to reach www.foo.com 👀
S --> C: ERROR_RESPONSE: (Error = REMOTE_ADDR_UNALLOWED, Client ID
= 3)rip, the gateway says no 💀 the host isn't allowed to talk to www.foo.com
C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address (local) =
0, Address (remote) = www.bar.com, Ports (remote) = 0, Lease
Time = 3600, Tunnel Type = IP-IP)the host tries again with a different destination 🔁 this time it asks for a local address and says it wants to reach www.bar.com
S --> C: ASSIGN_RESPONSE_RSA-IP: (Client ID = 3, Bind ID = 1,
Address (local) = 149.112.240.17, Address (remote) =
www.bar.com, Ports (remote) = 0, Lease Time = 3600, Tunnel Type
= IP-IP)YES, the gateway grants local IP address 149.112.240.17 and lets the host talk to www.bar.com on any port 🎉 the requested lease time and tunnel type are granted too 🥳
C --> S: DE-REGISTER_REQUEST (Client ID = 3)the host de-registers with the server 🫶
S --> C: DE-REGISTER_RESPONSE (Client ID = 3)the gateway acknowledges the de-registration, and all of the host's bindings have been implicitly revoked 🧚
17. Appendix D: Example RSIP host state diagram 🦋
this appendix is an example diagram of RSIP host state 🗺️ the host starts out in the unregistered state. we're assuming that for UDP, if a message gets lost, the host times out and sends another copy of it. we recommend a 7-fold binary exponential backoff timer for retransmissions, with the first timeout happening after 12.5 ms ⏱️ this diagram doesn't include any transitions for the LISTEN_REQUEST message
send
REGISTER_REQUEST
+------------+ +------------+
| |------------->|Registration|<-- timeout/send
+--->|Unregistered|<-------------| Pending |--- REGISTER_REQUEST
| | | +------------+
| +------------+ 7th timeout/recv |
| ^ ERROR_RESPONSE |
| | |
| | |
| |7th timeout/recv |recv timeout/send
| |DE-REGISTER_RESPONSE |REGISTER_RESPONSE QUERY_REQUEST
| | | ^ |
| | | | |
| | | send | |
| | send DE- v QUERY_REQUEST | |
| +----------------+ REGISTER_REQUEST+----------+ +----------+
| | Registered |<----------------| |--------->|Registered|
| | De-registration| |Registered| | Query |
| | Pending |---------------->| |<---------| Pending |
| +----------------+ recv +----------+ +----------+
| | ^ ERROR_RESPONSE ^ | 7th timeout/recv
| | | | | QUERY_RESPONSE or
| timeout/send | | ERROR_RESPONSE
| DE-REGISTER_REQUEST 7th timeout/recv| |
| ERROR_RESPONSE | |
| | |
| +----------------+ | |
| |Go to Registered| | |send
| +----------------+ | |ASSIGN_REQUEST
| ^ timeout/send | |
| |Yes FREE_REQUEST | |
| + | | | |
| + + v | | v
| + + 7th timeout/ +--------+ +----------+
| + Are all + recv | Free | |Assignment|<--timeout/send
| + resources +<-----------|Pending | | Pending |---ASSIGN_REQUEST
| + freed? + FREE_RESPONSE+--------+ +----------+
| + + ^ | |
| + + | | |
| + | | |recv
| |No send | |recv |ASSIGN_RESPONSE
| v ERROR_REQUEST| |ERROR_ |
| +---------------+ | |RESPONSE |
| | Go to Assigned| | | | 7th timeout/recv
| +---------------+ | | | QUERY_RESPONSE or
| recv | | | ERROR_RESPONSE
| +---------------+ERROR_RESPONSE | v v +-----------+
| | Assigned |-------------->+-------------+-------->| Assigned |
+>|De-registration| | Assigned | | Query |
| Pending |<--------------+-------------+<--------| Pending |
+---------------+ send ^ | +-----------+
^ | DE-REGISTER_REQUEST | | send ^ |
| | | | QUERY_REQUEST | |
| | | | | |
timeout/send 7th/timeout/recv | |send | |
DE-REGISTER_ ASSIGN_RESPONSE | |ASSIGN_REQUEST timeout/send
REQUEST or ERROR_RESPONSE| | QUERY_REQUEST
| |
| v
+----------+
| Assigned |
|Assignment|
| Pending |
+----------+
^ |
| |
timeout/send
ASSIGN_REQUEST18. References 📚
- [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.
- [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
- [RSIP-FRAME] Borella, M. Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
- [RSIP-IPSEC] Montenegro, G. and M. Borella, "RSIP Support for End-to-end IPSEC", RFC 3104, October 2001.
19. Authors' Addresses 🌟
Michael Borella
CommWorks
3800 Golf Rd.
Rolling Meadows IL 60008
Phone: (847) 262-3083
EMail: mike_borella@commworks.com
David Grabelsky
CommWorks
3800 Golf Rd.
Rolling Meadows IL 60008
Phone: (847) 222-2483
EMail: david_grabelsky@commworks.com
Jeffrey Lo
Candlestick Networks, Inc
70 Las Colinas Lane,
San Jose, CA 95119
Phone: (408) 284 4132
EMail: yidarlo@yahoo.com
Kunihiro Taniguchi
NEC USA
C&C Research Labs.
110 Rio Robles
San Jose, CA 95134
Phone: (408) 943-3031
EMail: taniguti@ccrl.sj.nec.com20. Full Copyright Statement 💖
Copyright (C) The Internet Society (2001). All Rights Reserved. 🌈
Okay bestie, the legal bit is here 💅 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. The one condition is 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. The exceptions are: needed for developing Internet standards (in which case the procedures for copyrights defined in the Internet Standards process must be followed), or 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. Forever and ever, no take-backs 🫶
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 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 👑
📦 where this page comes from
- ietf: rfc3103 2001-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms