RE: [rip] Version Number Processing
gmalkin@toplayer.com Mon, 15 March 2004 16:25 UTC
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07772 for <rip-archive@ietf.org>; Mon, 15 Mar 2004 11:25:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2uuR-0000AM-00 for rip-archive@ietf.org; Mon, 15 Mar 2004 11:25:47 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2usX-0007TK-00 for rip-archive@ietf.org; Mon, 15 Mar 2004 11:23:49 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B2urL-0007D8-02; Mon, 15 Mar 2004 11:22:36 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B2ulz-00037i-KC; Mon, 15 Mar 2004 11:17:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ulw-0001Lf-PV; Mon, 15 Mar 2004 11:17:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ulq-0001LH-Md for rip@optimus.ietf.org; Mon, 15 Mar 2004 11:16:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06841 for <rip@ietf.org>; Mon, 15 Mar 2004 11:16:52 -0500 (EST)
From: gmalkin@toplayer.com
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2ulp-0006Ev-00 for rip@ietf.org; Mon, 15 Mar 2004 11:16:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2uko-00062E-00 for rip@ietf.org; Mon, 15 Mar 2004 11:15:50 -0500
Received: from mail.toplayer.com ([66.100.252.67] helo=tlnmail1.toplayer.com) by ietf-mx with esmtp (Exim 4.12) id 1B2uji-0005sn-00 for rip@ietf.org; Mon, 15 Mar 2004 11:14:42 -0500
Received: by tlnmail1.toplayer.com with Internet Mail Service (5.5.2657.72) id <G5XTSYGP>; Mon, 15 Mar 2004 11:14:07 -0500
Message-ID: <F6242D340921D5118D1E00508BB9837A04BBB6A8@tlnmail1.toplayer.com>
To: js@iol.unh.edu, rip@ietf.org
Subject: RE: [rip] Version Number Processing
Date: Mon, 15 Mar 2004 11:13:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Sender: rip-admin@ietf.org
Errors-To: rip-admin@ietf.org
X-BeenThere: rip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rip>, <mailto:rip-request@ietf.org?subject=unsubscribe>
List-Id: Routing Information Protocol Working Group <rip.ietf.org>
List-Post: <mailto:rip@ietf.org>
List-Help: <mailto:rip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rip>, <mailto:rip-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60
Joe, The reason the spec does not cover this case is that it depends on the difference between V3 and V2. If the V3 packet is completely backwards compatible with a V2 packet (i.e., the only difference is in a field unused by V2), then the V2 router could respond with a V2 packet. The V3 router should be able to handle a V2 response. Ideally, it would remember that there is a V2 router on that interface and use V2 on it thereafter. If the V3 packet is not backwards compatible, then the V2 router must drop the V3 packet. Unfortunately, since the V2 code is already out there, it doesn't know which scenario is the correct one, so its operation is implementation dependent. Gary Malkin Cheap, fast, good... 508-870-1300 x254 Pick two! -----Original Message----- From: Joseph Scholefield [mailto:js@iol.unh.edu] Sent: Monday, March 15, 2004 10:59 AM To: rip@ietf.org Subject: [rip] Version Number Processing Hello, We have encountered a number of scenarios which are not too clearly described in the RIP 2 Specification, RFC2453. We are concerned with how a RIP Router should handle the reception of RIP Version 3 packets (anything greater than 2). Section 5 states As a V1 Router: - Version 1 packets with MBZ with non-zero fields are to be ignored - Version >1 packets with MBZ with non-zero fields are not to be ignored "simply because an MBZ field contains a value other than zero." Does this hold true as a V2 Router? So, does a version 2 router process, or drop, a version 3 RIP packet? Should this packet be a Request, should a RIP Router then respond with a Version 3 Response? I have read through the RFC and have not come up with any clear answer to the expected behavior. If you could direct me to specific quotes in the RFC that will tell me what a router should do, I would appreciate it. Thanks, Joe Scholefield _______________________________________________ rip mailing list rip@ietf.org https://www1.ietf.org/mailman/listinfo/rip _______________________________________________ rip mailing list rip@ietf.org https://www1.ietf.org/mailman/listinfo/rip
- [rip] Version Number Processing Joseph Scholefield
- RE: [rip] Version Number Processing gmalkin