Browse Prior Art Database

Method to discover Realm Specific IP server in multicast and broadcast networks using ICMP Disclosure Number: IPCOM000028927D
Original Publication Date: 2004-Jun-08
Included in the Prior Art Database: 2004-Jun-08
Document File: 5 page(s) / 35K

Publishing Venue



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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 45% of the total text.

Page 1 of 5

Method to discover Realm Specific IP server in multicast and broadcast networks using ICMP

Message Formats

The existing format specification of ICMP Router advertisement and Solicitation messages are as follows. The suggested changes to code field and semantics for other fields are indicated in blue .

ICMP Router Advertisement Message/ICMP RSIP Server Advertisement Message

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 | Code | Checksum |


| Num Addrs |Addr Entry Size| Lifetime |


| Router Address[1] |


| Preference Level[1] |


| Router Address[2] |


| Preference Level[2] |


| . |

| . |

| . |

IP Fields:

Source Address An IP address belonging to the interface

from which this message is sent.

Destination Address The configured AdvertisementAddress or the

IP address of a neighboring host.

This will be multicast all host address

( when it is used for RSIP Server



This will be the multicase group address for which

this RSIP server is the group leader


This will be the unicast address of the client

from which server received server solicit message

Time-to-Live 1 if the Destination Address is an IP

multicast address; at least 1 otherwise.

ICMP Fields:

Type 9

Code 0

1 RSIP Server Advertisement


Page 2 of 5

Checksum The 16-bit one's complement of the one's

complement sum of the ICMP message, start-

ing with the ICMP Type. For computing the

checksum, the Checksum field is set to 0.

Num Addrs The number of router addresses advertised

in this message.

Number of RSIP Server addresses advertised in this


Addr Entry Size The number of 32-bit words of information

per each router address (2, in the version

of the protocol described here).

The number of 32-bit words of information per each

RSIP Server address. It will always be 1 in the

case of messages with code=1 (RSIP Server


Lifetime The maximum number of seconds that the

router addresses may be considered valid.

The maximum number of seconds that the

RSIP Server address may be considered valid.

Router Address[i], The sending router's IP address(es) on the

i = 1..Num Addrs interface from which this message is sent.

The sending RSIP Server's IP address(es) on the

interface from which this message is sent.

Preference Level[i], The preferability of each Router Address[i]

i = 1..Num Addrs as a default router address, relative to

other router addresses on the same subnet.

A signed, twos-complement value; higher

values mean more preferable.

Currently Not used in the case...