idnits 2.17.1 draft-ietf-udlr-rip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 110 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1997) is 9631 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Emmanuel Duros 3 Internet-Draft Christian Huitema 5 INRIA Sophia-Antipolis 7 November 1997 9 Handling of unidirectional links with RIP 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as ``work in progress.'' 31 To learn the current status of any Internet-Draft, please check the 33 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 35 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 37 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 39 ftp.isi.edu (US West Coast). 41 Abstract 43 This document defines the modifications which can be applied to RIP 44 [rfc1723] which make the communication over asymmetric links 45 feasible. 47 1. Introduction 49 RIP is one of the first dynamic routing protocols used in the 51 internet known as Internal Gateway Protocol. It was designed to work 53 on networks where adjacent gateways communicate using the same link 55 in both directions. Links may be asymmetric, e.g., have different 57 delays and throughputs in different directions, but they have to be 59 duplex. 61 2. Overcoming RIP restrictions 62 A satellite network comprises two sets of stations, feeds that can 64 both send and receive packets, and receivers that can only receive 66 packets. 68 Feeds must be allowed to forward over the satellite links the packets 70 which are bound to subnets accessible through other feeds or through 72 receivers. 74 Receivers will never send any packet via the satellite link. They 76 must however send reports to the feeds to indicate the subnets for 78 which they are ready to receive packets. 80 If the network included only feeds, RIP could be used almost 82 unchanged. Usage by a mix of receivers and feeds requires some 84 extensions. 86 3. Proposed solution 88 In our example we assume that G1 and G2 (Gateways) are connected to 90 symmetric and asymmetric networks (See Figure 1). Using RIP, G1 does 92 not consider G2 as a neighbor because the link is unidirectional and 94 therefore will send packets to the regular connections (route N3). 96 route N1 98 N2 ---- ---- N5 100 ---========>|G1| ===================> |G2|<==========--- 102 ---- update msg ---- 104 /\ /\ 106 || ------------------ || 108 ====| regular |==== 110 N3 | connections | N4 112 ------------------ 114 Figure 1 116 To avoid such behavior, G1 should consider G2 as a neighbor. RIP 118 should be modified to take into account unidirectional links. 120 RIP messages are composed of a succession of 20 bytes segments. The 122 first segment may be an authentication code. All other segments are 124 subnet-distance pairs. We propose to associate a specific 126 authentication with the satellite network. The handling of this code 128 will be different by feeds and receivers. 130 3.1. Handling by receivers 131 Upon reception of a RIP packet, receivers examine the authentication 133 code. They note that this packet was sent by a satellite feed. They 135 will ignore all subnet-distance announces contained in this packet, 137 but they will add the source address of the packet [IP source] to the 139 list of "potential feeds". 141 At pseudo-regular intervals, the receivers will send to the potential 143 feeds a RIP packet that will be authenticated as a "satellite 145 packet". This packet, however, will not be sent to the regular 147 multicast address of all the RIP routers. Instead, a copy of this 149 packet will be sent to the unicast address of each feed. 151 This procedure assumes that there is another route, beside the 153 satellite link, by which the receiver can send packets to the feed. 155 3.2 processing by feeds 157 Processing of RIP packets by feeds is almost unchanged, except the 159 following : 161 - all packets sent over the multicast link are authenticated. 163 - all packets that are authenticated as satellite packets are 165 processed even if they routed by another interface. 167 References 169 [rfc1723] Malkin, G., "RIP Version 2 - Carrying Additional 171 Information", Request For Comments (RFC) 1723, Xylogics, 173 Inc., November,1994. 175 Author's address 177 Emmanuel Duros 179 INRIA Sophia Antipolis 181 2004, Route des Lucioles BP 93 183 06902 Sophia Antipolis CEDEX France 185 Email : Emmanuel.Duros@sophia.inria.fr 187 Phone : +33 93 65 78 15 189 Christian Huitema 191 INRIA Sophia Antipolis 193 2004, Route des Lucioles BP 93 195 06902 Sophia Antipolis CEDEX France 197 Email : huitema@sophia.inria.fr