Subject: RIPng question

From: Ray LaRocca <[email-masked]>
Date: Wed, 15 Mar 2000 17:35:57 -0500

We're testing RIPng here at the IPv6 Forum meeting and ran across a
question- if anyone can shed some light on this we would appreciate it:

In IPv4 it's obviously pointless to claim reachability for a network on 
the actual network.  

In IPv6 there may be a case where two routers with interfaces on the same
network have different prefixes for that same network.  The question
is: should a RIPng router advertise its prefix for a network as reachable 
on that actual network since other routers may or may not know that
prefix.

-Ray

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 15 Mar 2000 15:13:24 -0800 (PST)

> on that actual network since other routers may or may not know that

Hi Ray,
Good point. We encountered same issue while testing IPv6 in our lab.
The problem is that routers advertising different prefixes on the
same link do not know about each other's prefix as they don't
process the router advertisement sent by other routers.
Thus a node cannot reach another node beyond the 2nd router 
in the journey. 
I think, RIPng somehow must be smart enough to listen to the 
routing advertisement and then figure out if advertised prefixes are
same as it's own prefix on the same link, if they are not the
same, then it can add that route in it's own system. I can see a problem
of RIPng advertising it's own prefix as reachable as there may be
two routers advertising same prefix on the link and the third one (on same
link) advertising a different prefix.
Another simple solution is to make routers advertise same prefix
on the same link-- that needs some modification in the drafts/rfcs.

-Samita

---

From: Sowmini Varadhan <[email-masked]>
Date: Thu, 16 Mar 2000 08:59:17 -0500 (EST)

>From [email-masked] Wed Mar 15 19:36:58 2000
>

>process the router advertisement sent by other routers.

This is only a problem in that they are not aware of the prefix
as being "on-link".

>Thus a node cannot reach another node beyond the 2nd router 

If there are 2 routers Ra and Rb on a network advertising prefixes
Pa and Pb,  nodes that are not routers should autoconfigure all of the 
advertised prefixes, and should have both Ra and Rb on their
default router list. I'm not sure I see the problem you are listing
above.  Could you please illustrate this with an example?

A possible kink is that since Ra may possibly not know that Pb is an
on-link prefix, but since Rb should be sending out ripng advs on the 
link saying that Pb with metric 1, Ra should have the routing information 
to route packets with prefix Pb through Rb.  How is reachability affected?

>on the same link-- that needs some modification in the drafts/rfcs.

I don't think this is a good idea- there may be a valid need to 
autoconfigure more than one prefix on a network, and the above suggestion
would preclude that case. 

--Sowmini

---

From: "Powell, Ken" <[email-masked]>
Date: Fri, 17 Mar 2000 12:33:28 -0500

Hi,

A little more background may be needed for this issue.
UNH noticed at the Telluride test event that when
sending a RIP advertisement on a LAN, different
venders handle the LAN's own prefix different ways.
The three policies seen were:

  1) Do not include the LAN's prefix in the RIP advertisement.
  2) Include the LAN's own prefix with a metric of 1.
  3) Include the LAN's own prefix with a metric of 16.

The spec does not say what to do in this situation and we
did not notice any interoperability problems.

The configuration Ray described is a case we thought of where
it seems the policy implemented by the router vendor could make
a difference. Is this something that needs to be specified, or
can we live with vendor's choice here?

Ken

-----Original Message-----
From: Sowmini Varadhan [mailto:[email-masked]]
Sent: Thursday, March 16, 2000 8:59 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: RIPng question

--Sowmini

---

From: Sowmini Varadhan <[email-masked]>
Date: Fri, 17 Mar 2000 13:27:33 -0500 (EST)

>did not notice any interoperability problems.

RFC 2080 says:

2.5.2  Generating Response Messages
	:
	:
   To fill in the RTEs, examine each route in the routing table.  Routes
   to link-local addresses must never be included in an RTE.  If a
   triggered update is being generated, only entries whose route change
   flags are set need be included.  If, after Split Horizon processing,
   the route should not be included, skip it.  If the route is to be
   included, then the destination prefix, prefix length, and metric are
   put into the RTE.  The route tag is filled in as defined in section
   2.1.  Routes must be included in the datagram even if their metrics
   are infinite.

Note  that #2  would  comply with Section 2.5.2. It also appears to
eliminate policy #1 (the only routes that are to be skipped
are link-locals, those eliminated by Split Horizon, and, in the case
of triggered updates, those whose route flags have not changed).

As for policy #3,  RFC2080 says:

2.6  Split Horizon

   Split Horizon is a algorithm for avoiding problems caused by
   including routes in updates sent to the gateway from which they were
   learned.  The basic split horizon algorithm omits routes learned from
   one neighbor in updates sent to that neighbor.  In the case of a
   broadcast network, all routes learned from any neighbor on that
   network are omitted from updates sent on that network.

   Split Horizon with Poisoned Reverse (more simply, Poison Reverse)
   does include such routes in updates, but sets their metrics to
   infinity.  In effect, advertising the fact that there routes are not
   reachable.  This is the preferred method of operation; however,
   implementations should provide a per-interface control allowing no
   horizoning, split horizoning, and poisoned reverse to be selected.

The onlink prefix is not  a route that a router "learned from a gateway",
so I don't see how it can justifiably be sent with metric 16.

--Sowmini

---

From: [email-masked]
Date: Tue, 28 Mar 2000 19:03:42 -0800 (PST)

> above.  Could you please illustrate this with an example?

The example in my mind is :

          Pa--->           <----Pb            Pn--->
--------                               ------
|      |------------------------------|     |----------------
|  Ra  |               |              | Rb  |               |
|-------             --------         -------              -----
                     | Node1 |                             |      |
                     |       |                             | node2|
                     --------                              --------
                        Pa:X
                        Pb:X                                  Pn:Y

Now if node2 wants to  do "ping Node1" with address Pa:X, then Pa:X will
be unreachable from node2. Because Rb does not autoconfigure with
other router's advertisements and RIPNG of Ra advertises Pa with 
metric 16 on the link, so Rb will not be able to resolve the route
for 'Pa:X'.
However, node2 will not have have any problem reaching Node1 using
address Pb:X. So it depends what address of Node1 is returned by the
name server of node2.

-Samita

---

From: Sowmini Varadhan <[email-masked]>
Date: Wed, 29 Mar 2000 09:20:57 -0500 (EST)

>From [email-masked] Tue Mar 28 22:09:04 2000
>

Only if Ra was not advertising Pa with metric 1 on the link between
Ra and Rb. 

If Ra was advertising Pa with metric 1 (as I believe it should, according
to RFC 2080, Section 2.5.2) then Rb would forward packets with 
{src Pn:Y, dst: Pa:X} to Ra, and then Ra would forward the packet to Node 1.

Ra may send a redirect to Rb while forwarding the packet to Node 1, 
and Rb would ignore the redirect (as it should), but there's no 
unreachability problem between Pn:Y and Pa:X here.

>metric 16 on the link, so Rb will not be able to resolve the route
 ^^^^^^^^^^^^^^^^^^^^^

Where does the RFC 2080 require or specify this? 

Please see Section 2.6 in RFC 2080, which I have quoted in my previous 
message dated Fri, 17 Mar 2000 13:27:33 -0500 (EST)) on this thread. 

--Sowmini