INTERNET-DRAFT                                   Massimo Torre, Ph.D.
Document: draft-massimo-rip-cor-00.txt     
Expires: February 2002                   
    
    


                        Comments on RFC 2453
    


    
Status of this Memo:
    
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.
    
    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."
    
    The list of current Internet-Drafts can be accessed at
    <http://www.ietf.org/ietf/1id-abstracts.txt>.
    
    The list of Internet-Draft Shadow Directories can be accessed at
    <http://www.ietf.org/shadow.html>.
    
    This draft must be intended as an individual submission to the "RIP"
    working group of the IETF.    
    


Table of Contents
    
    1.  Abstract
    2.  Purpose
    3.  Abbreviations
    4.  The Problem
    5.  Configuration scheme
    6.  Current RFC
    7.  Summary
    8.  Disclaimer
    9.  Author's address
     
    


1.  Abstract
    
    This draft is intended to point out a difference of behaviour between
    the RIP protocol as described in the RFC 2453 (also STD 56) and the
    RIP protocol as implemented by many vendors.

    If all the vendors apply the same rule, no problem arises. But, on the
    contrary, serious problems of interoperability can occur.



2.  Purpose

    The main purpose of this document is to receive an answer to the above
    mentioned problem; that's, more or less:
    a) I'm wrong or I've not completely undertood the overall process;
    b) I'm right, but it's normal to have such a difference;
    c) I'm right, and this document provide IETF RIP working group with an
       input for updating the current RFC.



3.  Abbreviations

    RIP = Routing Information Protocol
    I-D = Internet Draft
    MIN = Minimum
    RFC = Request For Comments
    STD = Standard
    i.e. = id est = that is
    e.g. = exempli gratia = for example
    etc. = et cetera = other
    
    
    
4.  The Problem
    
    Let's imagine this simple configuration: two routers directly connected
    to each other independently of the medium, i.e. point to point connection
    through ethernet, modem, or whatever else.
    In the process of sending a RIP update message from the sending router
    (let's call "A" from now on) to the receiving router (let's call "B"),
    the metric inside the RIP packet is already updated to the final value, while
    the standard specifies that the final value of the metric must be set by B.

    For example, if the routing table of A contains a route for a certain
    destination, and the metric for this route is 4 (hop count metric), what
    should happen according to the standard is that the number 4 is transmitted
    inside the RIP packet to B, and B adds 1 (the hop count for the direct
    connection) during the updating process of its routing table.
    Instead, what really happens, is that the metric inside the RIP packet is
    already set to 5 (=4+1) by A, and B has to do nothing other than the normal
    check of the message.
        


5.  Configuration scheme

    The above configuration example is very simple; however I'll go in details
    through the description of the scheme I used to discover the difference
    between the standard and the real behaviour of routers.

    I connected A and B through an ethernet cable, and I in the middle of that
    I inserted a simple hub with a third port connected to a PC, which was running
    the "Sniffer Pro" (Network Associates, Inc.) application program.
    By watching at the RIP packets exchanged by the two routers, I discovered
    the above mentioned behaviour.

    Routers used were from different vendors (e.g. Cisco, ACC, etc.).
    The RIP version used was either 1 and 2.



6.  Current RFC

    The current RFC (2453) about RIP v.2 says literally (paragraph 3.9.2,
    "Response Messages", page 27):

    <metric = MIN (metric + cost, infinity)>

    This is incorrect if compared to the real implementations. It may continue to
    be valid if the rule is intended during the outgoing processing (router A),
    not in the incoming processing (router B).



7.  Summary

    This brief I-D has pointed out one difference between the RIP protocol as
    described by RFC 2453, and the one implemented by many vendors.
    While point 1 has indicated the problem, point 2 has shown the purpose of
    the document, and points 4-7 have gone more deeply into the subject. 
    
    

8.  Disclaimer

    The opinions expressed in this draft are solely the author's.
    The worldwide company which I work for has not been mentioned.
    


9.  Author's address

    Massimo Torre
    Rome, Italy
    Fax: +39 06 233208654
    E.Mail: maxtow@altavista.net