Method to discover Realm Specific IP server in multicast and broadcast networks using ICMP
Original Publication Date: 2004-Jun-08
Included in the Prior Art Database: 2004-Jun-08
Realm Specific IP (RSIP) is a new architecture that is positioned to replace Network Address Translation (NAT) used for partitioning the network address space for reasons like shortage of IP V4 addresses and hiding the internal network details etc., RSIP scores over NAT for reasons like supporting end-to-end security via IPSEC which NAT cannot and also not requiring specific application level gateways (ALG) for supporting different protocols. RSIP protocol proposal involves RSIP client and RSIP server entities. RSIP server has the resources in the form of publicly available IP address(es) and port(s). RSIP server allocates them to RSIP clients upon receiving the signaling requests from the clients. RSIP client after receiving the public address and optionally port number, tunnels its packets (destined for a different realm address) to RSIP server. RSIP server strips the outer header of the tunneled packets from RSIP clients and forwards them to the target realm. Before client can invoke the services of an RSIP server, it must first locate the RSIP server. Currently, there are two proposed means using which RSIP clients can locate RSIP server a) Since on most networks, clients obtain their local addresses with DHCP, IETF is defining a DHCP option that informs clients of the address of the RSIP Server b) Since Service Location Protocol (SLP) defines a framework for query based discovery of services, an effort is going on to use this protocol for RSIP clients to discover RSIP server. This paper discusses a new and different technique to achieve RSIP server discovery with a lightweight framework based on ICMP which requires minimal extensions to be made to the already existing ICMP Router Advertisement and Router Solicitation messages. Also, this framework specifies minimal configuration requirements for RSIP client and RSIP server. The requirement to support these messages is that the RSIP servers and clients are required to be attached to networks that support multicast or broadcast. Existing message formats for the ICMP Router Advertisement and ICMP Router Solicitation have (type, code) tuple defined as (9,0) and (10,0) respectively. This framework defines extension for the code field of the existing messages and the semantics for the rest of the fields change slightly, to suit the context, which includes not using some of the fields.