Comments on RIP-II protocol and MIB specification.

[Jeffrey C Honig <[e-mail]>]

There are a few problems I've found with the RIP-II specs, I've listed
them here with proposed solutions I'd like to discuss.

I) Routing Domains

I've been told that the documentation on routing domains is not clear.
Here is some suggested replacement text.

	3.2	Routing Domains

	   A Routing Domain (RD) is a contiguous subset of the RIP-2
	   routers on a given collection of networks.  An RD enables
	   the propagation of multiple independent sets of routing
	   information and a given RIP-2 router may participate in
	   more than one Routing Domain on any given interface.
	   Authentication should be configurable separately for each
	   Routing Domain on a particular interface.

	   The default Routing Domain is zero (i.e. an RD field of
	   zero in RIP-2 packets); this is the default domain for
	   RIP-2 routers and the only domain supported by RIP-1
	   routers.  Support for RDs other than zero by RIP-2 routers
	   is optional; but rejection of packets with an unsupported
	   or unconfigured RD field is required.  RIP-2 routers should
	   default to be members of RD zero unless configured
	   otherwise.

	   RIP-2 routers must not ``leak'' routing information between
	   RDs unless explicitly configured to do so.  Routes with an
	   RD other than zero may only be sent via the RIP IP
	   multicast address to prevent misinterpretation by RIP-1
	   routers.


II) Route Tag

There is also some ambiguity about the use of the Route Tag field.
Hopefully this text is a bit more explicit.
	   
	3.3 Route Tag

	   The Route Tag (RT) field is an attribute assigned to a
	   route which must be preserved and readvertised with a
	   route.  The intended use of the Route Tag is to provide a
	   method of separating ``internal'' RIP routes (routes for
	   networks within a RIP routing domain) from ``external'' RIP
	   routes, which may have been imported from an egp or another
	   RIP domain.

	   Routers supporting protocols other than RIP should be
	   configurable to allow the Route Tag to be configured for
	   routes imported from different sources.  For example,
	   routes imported from EGP or BGP should be able to have
	   their Route Tag either set to an arbitrary value, or at
	   least to the number of the Autonomous System from which
	   the routes were learned.

	   Routers exporting RIP routes into other protocols should be
	   able to export a subset of all RIP routes based on the
	   Route Tag.  For example, only export RIP routes with a
	   Route Tag of zero to an EGP neighbor.

	   Other uses of the Route Tag are valid, as long as all
	   routers in the RIP domain use it consistently.  This allows
	   for the possibility of a BGP-RIP protocol interactions
	   document, which would describe methods for synchronizing
	   routing in a transit network.


III) Supernet routes

The spec does not address the issue of supernet routes (a.k.a. CIDR)
in the presence of RIP-1 routers.  The following suggested addition to
section 3.4 explicitly disallows sending them where RIP-1 routers are
listening.
	   
		3) Supernet routes (routes with a netmask less
		   specific than the "natural" network mask) may not be
		   advertized where they could be misinterpreted by
		   RIP-1 routers.


IV) Selective Reception
		   
The MIB defines a variable that controls selective reception of
routing protocols, but the protocol document makes no mention of this.
The following paragraph (to be inserted after section 4.1) documents
this functionality.

	4.x  Selective Reception

	   A RIP-2 capable router may be configurable to receive only
	   RIP-1, only RIP-2 or both RIP-1 and RIP-2 packets on a per
	   interface basis.  Enabling the reception of both RIP-1 or
	   RIP-2 packets, or just the reception of RIP-2 packets
	   implies the use of IP multicasting.


VI) Improper terms used

In section 4.3, the term ``long'' is used.  This should be ``four
octet''.  In general, the use of ``byte'' should be replaced by
``octet''.


V) MIB problems

  A) Routing Domains

    The MIB refers to RouteTag instead of RoutingDomain.

    The rip2IfConfTable, rip2IfStatTable and rip2PeerTable need to be
    indexed by RoutingDomain.

  B) Interface uniqueness

    Unix systems do not require that the local address of
    point-to-point interfaces be unique, only the remote address.  The
    MIB is unable to report this.  Although RIP does not support
    ``unnumbered'' interfaces, the same technique that is used in
    support of ``unnumbered'' interfaces can be used: add an
    AddressLessIndex to the INDEX of all tables that are indexed by
    interface address.  For unique interfaces this value should be
    zero, for non-unique interfaces, this should have value of the
    ifIndex for this interface.

  C) RIP Use of the IP Forwarding Table

    A section of the RIP-II MIB should be devoted to use of the IP
    forwarding table, as is done in the OSPF spec.

    The MIB does not allow for reporting the RouteTag of a given route
    and the RoutingDomain it was learned from.  Can this be
    accomplished via the ipForwardInfo field?  Or do we need to add
    another table?

  D) RIP Route table

    If the RouteTag and RoutingDomain can not be reported via existing
    mechanisms, I suggest Yet Another Mib Table, rip2Route.  But I
    hope we can use existing mechanisms.  I would imagine it being
    indexed by rip2RouteDest, rip2RouteMask, rip2RouteDomain.

    	rip2RouteDest		The destination (network, subnet or host)
	rip2RouteMask		The associated subnet mask
	rip2RouteDomain		The routing domain it was learned from
	rip2RouteTag		The tag of this route
	rip2RouteGateway	The peer from which this route was
				learned.  This is not always the next
				hop.
	
Below are suggested changes to RFC 1389 for points A & B.  I've
presented them in GNU unified diff format mainly because I find it
easier to read.

Thanks.

Jeff
    
--- rfc1389.txt	Tue Jan 19 13:34:08 1993
+++ rfc1389-upd.txt	Tue Mar 30 17:04:25 1993
@@ -134,9 +134,8 @@
    of the elusive goal of clear, concise, and unambiguous MIB documents.
 
    The new data types are: Validation (the standard "set to invalid
-   causes deletion" type), and RouteTag.   The RouteTag type represents
-   the contents of the Route Tag field in the packet header or route
-   entry.
+   causes deletion" type), and RoutingDomain.  The RoutingDomain type
+   represents the identifier of a RIP-2 Routing Domain.
 
 3.2 Structure of MIB
 
@@ -172,10 +171,11 @@
 RFC 1389                  RIP-2 MIB Extension               January 1993
 
 
-   -- the RouteTag type represents the contents of the
-   -- Route Tag field in the packet header or route entry.
+   -- the RoutingDomain type represents the identifier of a RIP-2
+   -- Routing Domain as represented by the RoutingDomain field in a
+   -- RIP-2 packet header.
 
-   RouteTag ::= OCTET STRING (SIZE (2))
+   RoutingDomain::= OCTET STRING (SIZE (2))
 
    -- the Validation type is used for the variable that deletes
    -- an entry from a table, and ALWAYS takes at least these values:
@@ -244,8 +244,9 @@
           ACCESS   not-accessible
           STATUS   mandatory
           DESCRIPTION
-             "A Single Routing Domain in a single Subnet."
-         INDEX { rip2IfStatAddress }
+             "A Single Routing Domain on a single Subnet."
+         INDEX { rip2IfStatAddress, rip2IfStatAddressLessIndex,
+	 	 rip2IfStatDomain }
          ::= { rip2IfStatTable 1 }
 
 
@@ -253,6 +254,10 @@
            SEQUENCE {
                rip2IfStatAddress
                    IpAddress,
+	       rip2IfStatAddressLessIndex
+	           INTEGER,
+	       rip2IfStatDomain
+	           RoutingDomain,
                rip2IfStatRcvBadPackets
                    Counter,
                rip2IfStatRcvBadRoutes
@@ -273,6 +278,30 @@
           ::= { rip2IfStatEntry 1 }
 
 
+       rip2IfStatAddressLessIndex OBJECT-TYPE
+           SYNTAX   INTEGER
+	   ACCESS   read-only
+	   STATUS   mandatory
+	   DESCRIPTION
+              "For the purpose of easing the instancing of addressed
+              and addressless interfaces; This variable takes the
+              value 0 on interfaces having unique IP Addresses, and
+              the corresponding value of ifIndex for interfaces not
+              having a unique IP Address."
+	  ::= { rip2IfStatEntry ?? }
+	  
+
+       rip2IfStatDomain OBJECT-TYPE
+           SYNTAX   RoutingDomain
+           ACCESS   read-only
+           STATUS   mandatory
+           DESCRIPTION
+	      "The identifier of the Routing Domain for this table
+              instance".
+          DEFVAL { '0000'h }
+          ::= { rip2IfStatEntry ?? }
+
+
        rip2IfStatRcvBadPackets OBJECT-TYPE
            SYNTAX   Counter
            ACCESS   read-only
@@ -352,7 +381,8 @@
           STATUS   mandatory
           DESCRIPTION
              "A Single Routing Domain in a single Subnet."
-         INDEX { rip2IfConfAddress }
+         INDEX { rip2IfConfAddress, rip2IfConfAddressLessIndex,
+	         rip2IfConfDomain }
          ::= { rip2IfConfTable 1 }
 
 
@@ -360,8 +390,10 @@
            SEQUENCE {
                rip2IfConfAddress
                    IpAddress,
+	       rip2IfConfAddressLessIndex
+                   INTEGER,
                rip2IfConfDomain
-                   RouteTag,
+                   RoutingDomain,
                rip2IfConfAuthType
                    INTEGER,
                rip2IfConfAuthKey
@@ -386,8 +418,21 @@
           ::= { rip2IfConfEntry 1 }
 
 
+       rip2IfConfAddressLessIndex OBJECT-TYPE
+           SYNTAX   INTEGER
+           ACCESS   read-only
+           STATUS   mandatory
+           DESCRIPTION
+              "For the purpose of easing the instancing of addressed
+	      and addressless interfaces; this variable takes the
+              value 0 on interfaces having unique IP Addresses, and
+              the corresponding value of ifIndex for interfaces not
+              having a unique IP Address."
+	  ::= { rip2IfConfEntry ?? }
+	  
+
        rip2IfConfDomain OBJECT-TYPE
-           SYNTAX   RouteTag
+           SYNTAX   RoutingDomain
 
 
 
@@ -399,9 +444,8 @@
            ACCESS   read-write
            STATUS   mandatory
            DESCRIPTION
-              "Value inserted into the Routing  Domain  field
-              of all RIP packets sent on this interface."
-          DEFVAL { '0000'h }
+	      "The identifier of the Routing Domain for this table
+              instance."
           ::= { rip2IfConfEntry 2 }
 
 
@@ -541,7 +585,8 @@
           STATUS   mandatory
           DESCRIPTION
              "Information regarding a single routing peer."
-         INDEX { rip2PeerAddress, rip2PeerDomain }
+         INDEX { rip2PeerAddress, rip2PeerAddressLessIndex,
+	         rip2PeerDomain }
          ::= { rip2PeerTable 1 }
 
 
@@ -549,8 +594,10 @@
            SEQUENCE {
                rip2PeerAddress
                    IpAddress,
+	       rip2PeerAddressLessIndex
+	           INTEGER,
                rip2PeerDomain
-                   RouteTag,
+                   RoutingDomain,
                rip2PeerLastUpdate
                    TimeTicks,
                rip2PeerVersion
@@ -579,13 +626,27 @@
           ::= { rip2PeerEntry 1 }
 
 
+       rip2PeerAddressLessIndex OBJECT-TYPE
+           SYNTAX   INTEGER
+	   ACCESS   read-only
+	   STATUS   mandatory
+	   DESCRIPTION
+              "For the purpose of easing the instancing of addressed
+	      and addressless interfaces; This variable takes the
+              value 0 on interfaces having unique IP Addresses, and
+              the corresponding value of ifIndex for interfaces not
+              having a unique IP Address."
+	  ::= { rip2PeerEntry ?? }
+	  
+
        rip2PeerDomain OBJECT-TYPE
-           SYNTAX   RouteTag
+           SYNTAX   RoutingDomain
            ACCESS   read-only
            STATUS   mandatory
            DESCRIPTION
               "The value in the Routing Domain field  in  RIP
               packets received from the peer."
+          DEFVAL { '0000'h }
           ::= { rip2PeerEntry 2 }