Subject: [nemo] RIPng with NEMO again..

From: "jhon saint" <[email-masked]>
Date: Mon, 14 Jun 2004 19:38:34 +0000

|
              +----+
              | GW |
              +----+
                |
                |  3ffe:10::/64
                |
              --+-+---------------+-
                  |               |
3ffe:10::95/64    |               |   (3ffe:10::96/64,  fe80::aaa:bbbb)
fe80::ccc:ddd  +----+           +----+ 
               | HA |           | MR |
               +----+           +----+
                                  |
                                  | 3ffe:11::/64
                               ---+----

We are implementing a mobile router with MIPL as a homework(?).

Our MR acts only in explicit mode.

When MR is at home, MR runs a routing protocol(ripng)..

so, routing tables in this network is : (only for mobile network)
   +----------+----------------+----------------+---------------
   |          |   dest         |   gw           | dev ...
   +----------+----------------+----------------+------------------
   | HomeAgent| 3ffe:11::/64   | fe80::aaa:bbbb | ethx....
   +----------+----------------+----------------+------------------
   | Gateway  | 3ffe:11::/64   | fe80::aaa:bbbb | ethx...
   +----------+----------------+----------------+------------------

now MR moves out from its home link, and sends bu for home registration 

with prefix option (3ffe:11::/64) to HA.

(and stops running routing protocol on its egress interface)

Then, HA receives the bu message and sets up forwarding to MR's network

with tunnel.. and advertise its routing information to 
infrastructure(Gateway..:p)..

  at this point, routing tables in this network is :
   +----------+----------------+----------------+------------
   |          |   dest         |   gw           | dev ...
   +----------+----------------+----------------+----------------
   | HomeAgent| 3ffe:11::/64   | *3ffe:10::96*  | *Tunnel*
   +----------+----------------+----------------+----------------
   | Gateway  | 3ffe:11::/64   | fe80::aaa:bbbb | ethx...
   +----------+----------------+----------------+--------------

We expected that if HA advertises its routing table (about mobile network),

 GW updates its route to the mobile network..

   So, this was our expectation... -_-
   +----------+----------------+----------------+------------
   |          |   dest         |   gw           | dev ...
   +----------+----------------+----------------+----------------
   | HomeAgent| 3ffe:11::/64   | 3ffe:10::96    | Tunnel dev
   +----------+----------------+----------------+----------------
   | Gateway  | 3ffe:11::/64   |*fe80::ccc:dddb*| ethx...
   +----------+----------------+----------------+--------------

Sending ping from HA to MR's mobile network(3ffe:11::/64) works well.

but, GW can't...

We found GW didn't update its routing entry for the mobile network

until the entry is expired... (after the entry expired and deleted, GW 
finally update a

path to the mobile network with ripng message from HA and GW can ping to 
monet)

In RFC2080 (RIPng for IPv6), [page 13]
===========================
   " If there is an existing route, compare the next hop address to the
    address of the router from which the datagram came. If this datagram
    is from the same router as the existing route, reinitialize the
    timeout. Next, compare the metrics. If the datagram is from the
    same router as the existing route, and the new metric is different
    than the old one; or, if the new metric is lower than the old one; do
    the following actions:
     .....
     ... "

Because of this, when GW receives new route info from HA about monet,

GW ignores it. 

So...  we modified ripngd source code.. (we're using Zebra ripngd 0.94)

    ripngd.c / void ripng_route_process(...) / line 623

	  original code..
	    same = (IN6_ARE_ADDR_EQUAL (&rinfo->from, &from->sin6_addr)
        	    && (rinfo->ifindex == ifp->ifindex));
		    --
	    
	  modified code..
	    same = (IN6_ARE_ADDR_EQUAL (&rinfo->from, &from->sin6_addr)
        	    || (rinfo->ifindex == ifp->ifindex));
		    --

  So, my question is.. (sorry.. too too long...)

  Our modification to ripng is necessary for NEMO support ? or, is there
  
  any solution for this problem?
  
  or.. our solution is totally in a wrong way?

  please~ help us~

Thanks..~~

_________________________________________________________________
보다 빠르고 보기 편한 뉴스. 오늘의 화제는 MSN 뉴스에서 확인하세요.   
http://www.msn.co.kr/news/

---

From: "T.J.Kniveton" <[email-masked]>
Date: Mon, 14 Jun 2004 18:03:46 -0700

Thank you for bringing this up. We are happy to see that you are 
implementing NEMO and gaining operational experience between NEMO and a 
routing protocol. This is very good.

Now to your question:
There are processing rules under section 2.4.2 of RFC 2080. However, 
some of the rules are confusing and imply certain tests.  Let's look at 
the section on processing updates where a route already exists:

>    If there is an existing route, compare the next hop address to the
>    - Adopt the route from the datagram.  That is, put the new metric 
> in,
>      and adjust the next hop address (if necessary).
>
>    - Set the route change flag and signal the output process to trigger
>      an update.
>
>    - If the new metric is infinity, start the deletion process
>      (described above); otherwise, re-initialize the timeout.
>
>    If the new metric is infinity, the deletion process begins for the
>    route, which is no longer used for routing packets.  Note that the
>    deletion process is started only when the metric is first set to
>    infinity.  If the metric was already infinity, then a new deletion
>    process is not started.
>
Notice that in the first paragraph, each sentence/rule explicitly tests 
whether the datagram is from the same router as the existing route. 
However, the last paragraph does NOT make this test. By that logic, ANY 
router on the link can remove any route by setting its metric to 
infinity. This does not have to be malicious; any route set to infinity 
on one router will kill other routers' entries if processed this way.

If we assume that the rule for deletion does include an implied rule 
that the deletion comes from the same router as the existing route, 
then we have a problem. If the MR is on the same link as the HA and all 
the other routers, it will send a RIPng solicited response or regular 
update. This will contain the mobile network prefix (MNP) and a metric 
of 1. The receiving router will add the network cost (1), so it will 
put an entry in its routing table:

MNP		MR's HoA		2

This is fine. But now the MR goes away. What *should* happen is that 
the route should be deleted. It will be deleted if it times out, but 
otherwise we have to explicitly delete it.

If we read RFC 2080 literally, the HA could delete the entry by proxy, 
simply by putting a metric of 16 in its triggered update, and then send 
another one, with its own metric (2), which would go into the receiver 
as metric 3. The entries would be:

MNP		MR's HoA		16
and then
MNP		HA 			3

However, implementations might process this differently depending on 
whether they make this (dangerous) assumption. For instance, there 
could be a router just starting up that has a route with infinity 
because it does not yet know the correct route. If it advertises it on 
the link, it would cause the route entry for that prefix to be deleted 
on all other routers.

If we assume that the rule requires the advertisement to come from the 
router already in the routing entry, then we can not explicitly delete 
it (except in the corner case where the MR knows it's going away, 
before it leaves the link). This is because the triggered update must 
come from the MR itself, who has already left the link.

Options:
I'll present a few possible ways to handle this.

1. MR-raised metric
Under this scenario, the MR could advertise an artificially high 
metric, so that when it leaves the link, the HA's normal metric will 
capture the entry. For instance, the MR could advertise metric 2, or 
metric 5, for the MNP. When it leaves, the HA will receive a BU from 
the MR and send a triggered update with its own address as next hop, 
and metric 1 (received as 2).

2. MR lives on a link behind the HA
To me, this makes the most sense. There was a lot of negative comments 
on this, and maybe I'll address those in another note. But here's the 
crux of it:

The MR (and MNs) are ALWAYS served by their HA. Even when they're on 
the home network, the HA should be their default router. This can occur 
via a physical separate access link for MN/MRs, or it can occur by 
putting a routing entry in the HA and having the MRs on the same link. 
The MR never needs to send any RIPng messages; its mobility is handled 
by the HA, even in the RIP domain, as it should be.

3. Fix RFC
This would comprise 2 subparts:
a. Update the text we discussed above, to make it clear and 
deterministic.
b. Include a way to explicitly remove routes, other than by timeout, 
given that the router in the existing route entry has either crashed, 
powered down, or otherwise moved off link.
(Given that all neighbor routers are trusted equally, there should be 
no problem for one router to remove another's route entry if it knows 
the router is no longer reachable).

TJ