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

[James Kempf <kempf@docomolabs-usa.com>]

<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 are possible
on some link types even if the host remains on the same IP link.