a quick question about RIPng
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

a quick question about RIPng



Hello,

I have one quick question about RIPng.

Section 2.4.1 of RFC2080 says as follows:

   The Request is processed entry by entry. [...
   ...]  Examine the list of RTEs in the Request one by one.
   For each entry, look up the destination in the router's routing
   database and, if there is a route, put that route's metric in the
   metric field of the RTE.  If there is no explicit route to the
   specified destination, put infinity in the metric field.  Once all
   the entries have been filled in, change the command from Request to
   Response and send the datagram back to the requestor.

I'm not really sure what "(if) there is a route" exactly means.  Does
that mean:

A. if the routing database contains a route entry for the *same*
   destination prefix as that of the requested RTE, or
B. if the routing database contains a route entry that *covers* the
   destination prefix of the requested RTE,
or others?

For example, suppose a router that only has a default route entry (for
prefix ::/0) with a metric of 1 in its routing database, and it
receives a request asking for 2001:db8::/32.  According to
interpretation A, the router will return an infinity metric; according
to interpretation B, the router will return a metric of 1 (from the
default route, because it matches the requested prefix).

Which one is correct?  BTW: I've seen several (but a quite limited
number of) open source and commercial implementations, and all seem to
behave based on interpretation A.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei at isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.