Re: [DNA] Text on Router Reachability for draft-ietf-dna-protocol

[Christian Vogt <chvogt@tm.uka.de>]

Hi James,

some comments relating to the text you proposed for inclusion in
draft-ietf-dna-protocol-00.txt.

Neither RFC2461 nor RFC2462bis specify that a MN should prefer a default
router with a corresponding NC entry in REACHABLE state over a default
router with a NC entry in STALE, DELAY, or PROBE state.  This a bit
unfortunate and should be fixed IMO.

In your text, the MN sets the NC entry for a previous default router to
STALE state in case it does not receive a solicited RA from that router.
 This implies that the MN must wait a little while, after sending the
RS, until it can be sure that no more RAs will be received.

The procedure outlined below would faster because the MN selects a new
default router immediately when it gets the first RA:

(a)  Receive a trigger indicating a change in L2 attachment.

(b)  Set all NC entries corresponding to routers in the Default Router
List to STALE state.

(c)  Send an RS.

(d)  For each received unicast RA, add the sender of the RA to the
Default Router List, if need be, and set the corresponding NC entry to
REACHABLE state (as specified in section 5.2.5 of
draft-ietf-dna-protocol-00.txt).

(e)  At all times, prefer a default router with a NC entry in REACHABLE
state over a default router with a NC entry in STALE, DELAY, or PROBE state.

Note that step (b) does not prevent a MN from sending packets to its
current default router.  If the current default router is still
reachable, it will forward the packets.  Step (b) does not even imply
that the MN sends an NS (as part of NUD) for the current default router
if that router is still reachable.  This is because the NS is deferred
for 5 seconds (DELAY_FIRST_PROBE_TIME), and a solicited RA meanwhile
received from the current default router would abort the 5-seconds timer
and set the NC entry for the current default router to REACHABLE.

Also, in case the MN did not change L3 connectivity, the new default
router is likely to be the same as the previous default router, given
the algorithm for sending FastRAs.

Finally, the procedure outlined above is easier to implement:  The MN
does not need to remember from which router it gets an RA until it sets
the NC entries for routers, from which it did not get an RA, to STALE state.

Regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/


James Kempf wrote:

> <Greg, could you please forward this to the list if it doesn't make
> it>
>
> In the current DNAv6 solution draft (draft-ietf-dna-protocol-00.txt),
>  address reachability is discussed in Section 5.2.6 but there is no
> text discussing router reachablity after a potential Layer 2
> handover. This in contrast to the DNAv4 draft:
>
> http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-18.txt
>
> which specifies the use of unicast ARP to the mobile node's current
> default
> router in order to confirm bidirectional reachability. Bernard
> Abboba's draft on architectural link indications:
>
> http://www.iab.org/documents/drafts/draft-iab-link-indications-04.txt
>
>
> contains an excellent discussion of why bidirectional reachability
> tests at
> the IP layer are necessary for 802.11-like protocols (they aren't for
>  cellular, but that is a different story).
>
> Since the current draft says nothing about router reachability
> detection, the mobile node would fall back to the NUD procedure
> described in Section 7.3 of RFC 2461, which does not distinguish
> between routers and other nodes.
> This procedure is likely to be lengthy, and is completely unnnecesary
>  because the mobile node has already confirmed reachability through
> the multicast DNA RS/unicast DNA RA. So the need is for some text in
> draft-ietf-dna-protocol-00.txt to specify how the mobile node uses
> this information to update its Default Router List.
>
> Below is some proposed text for this (thanx to Christian Vogt for
> help in formulating it). Please send comments.
>
> jak
>
> -----------------------------
>
> Remove the last paragraph in Section 5.2.5, put in the following new
> section after Section 5.2.5.1.
>
> 5.2.5.2 Router Reachability Detection and Default Router Selection
>
> The receipt of a unicast RA from a router in response to a multicast
> RS indicates that the host has bi-directional reachability with the
> routers that responded. Such reachability is necesary for the host to
> use a router as a default router, in order to have packets routed off
> the host's current
> link. If the destination address of the received RA is a unicast
> address, the host knows the router heard its RS, and hence it SHOULD
> mark that router's Neighbor Cache Entry [3] as REACHABLE, or add a
> Neighbor Cache Entry in the REACHABLE state if one does not currently
> exist. If the host fails to receive an RA from one of the routers on
> the Default Router List, the host SHOULD mark the Neighbor Cache
> entry of such routers as STALE, until reachability is again confirmed
> or until the entry is removed.
>
> The host SHOULD also update its Default Router List in the following
> fashion. If any of the routers returning RAs are already on the
> default router list, the host SHOULD use the information in the RA to
> update the Default Route List entry for that router. The host SHOULD
> add entries to the
> Default Router List for any routers returning RAs that are not on the
> list.
> As in RFC 2461, the host SHOULD confine selection of a router from
> the Default Router List to those routers whose Neighbor Cache entries
> are in the
> REACHABLE state. Note that the Default Router List SHOULD be updated
> as described here regardless of whether the RA indicates that the
> host has changed to a new IP link, since changes in router
> reachability arepossible
> on some link types even if the host remains on the same IP link.