[DNA] Text on Router Reachability for DNA Protocol Specification

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

In line with Greg's posting about combining drafts, I'm reposting a proposal 
I made after the Dallas IETF about adding some text about router 
reachability to the DNA protocol draft. The text would go into whichever 
draft dealt with host specifications. The problem is that 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 and discusses router
reachability extensively. 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). If anybody has suggestions for improvement, please
send them so we can have a discussion. I would like to propose
to the WG that this text be accepted into the merged protocol document
when it is decided.

                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 necessary 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 therefore that the host
has reachability with the router.

Prior to sending a DNA RS in response to an indication of link change,
the host SHOULD set all Neighbor Cache entries for routers on its Default
Router List to STALE. When the host receives an RS in reply to the RA, the
host 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.

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 with the new information. The host SHOULD
add entries to the Default Router List for any routers returning RAs that
are not on the list.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.

Note that this procedure does not prevent a MN from sending packets to its
current default router while the RA solicitation is in progress and if
reachability with the current default router is unchanged, there should
be no change in default router after the RA solicitation completes. If the
current default router is still reachable, it will forward the packets.