Network Working Group Emmanuel Duros Internet-Draft Christian Huitema INRIA Sophia-Antipolis November 1997 Handling of unidirectional links with RIP Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document defines the modifications which can be applied to RIP [rfc1723] which make the communication over asymmetric links feasible. 1. Introduction RIP is one of the first dynamic routing protocols used in the internet known as Internal Gateway Protocol. It was designed to work on networks where adjacent gateways communicate using the same link in both directions. Links may be asymmetric, e.g., have different delays and throughputs in different directions, but they have to be duplex. 2. Overcoming RIP restrictions Duros & Huitema [Page 1] Internet Draft Unidirectional links and RIP 15 March 1996 A satellite network comprises two sets of stations, feeds that can both send and receive packets, and receivers that can only receive packets. Feeds must be allowed to forward over the satellite links the packets which are bound to subnets accessible through other feeds or through receivers. Receivers will never send any packet via the satellite link. They must however send reports to the feeds to indicate the subnets for which they are ready to receive packets. If the network included only feeds, RIP could be used almost unchanged. Usage by a mix of receivers and feeds requires some extensions. 3. Proposed solution In our example we assume that G1 and G2 (Gateways) are connected to symmetric and asymmetric networks (See Figure 1). Using RIP, G1 does not consider G2 as a neighbor because the link is unidirectional and therefore will send packets to the regular connections (route N3). route N1 N2 ---- ---- N5 ---========>|G1| ===================> |G2|<==========--- ---- update msg ---- /\ /\ || ------------------ || ====| regular |==== N3 | connections | N4 ------------------ Figure 1 To avoid such behavior, G1 should consider G2 as a neighbor. RIP should be modified to take into account unidirectional links. RIP messages are composed of a succession of 20 bytes segments. The first segment may be an authentication code. All other segments are subnet-distance pairs. We propose to associate a specific authentication with the satellite network. The handling of this code will be different by feeds and receivers. 3.1. Handling by receivers Duros & Huitema [Page 2] Internet Draft Unidirectional links and RIP 15 March 1996 Upon reception of a RIP packet, receivers examine the authentication code. They note that this packet was sent by a satellite feed. They will ignore all subnet-distance announces contained in this packet, but they will add the source address of the packet [IP source] to the list of "potential feeds". At pseudo-regular intervals, the receivers will send to the potential feeds a RIP packet that will be authenticated as a "satellite packet". This packet, however, will not be sent to the regular multicast address of all the RIP routers. Instead, a copy of this packet will be sent to the unicast address of each feed. This procedure assumes that there is another route, beside the satellite link, by which the receiver can send packets to the feed. 3.2 processing by feeds Processing of RIP packets by feeds is almost unchanged, except the following : - all packets sent over the multicast link are authenticated. - all packets that are authenticated as satellite packets are processed even if they routed by another interface. References [rfc1723] Malkin, G., "RIP Version 2 - Carrying Additional Information", Request For Comments (RFC) 1723, Xylogics, Inc., November,1994. Author's address Emmanuel Duros INRIA Sophia Antipolis 2004, Route des Lucioles BP 93 06902 Sophia Antipolis CEDEX France Email : Emmanuel.Duros@sophia.inria.fr Phone : +33 93 65 78 15 Christian Huitema INRIA Sophia Antipolis 2004, Route des Lucioles BP 93 06902 Sophia Antipolis CEDEX France Email : huitema@sophia.inria.fr Duros & Huitema [Page 3]