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

[Greg Daley <gregd@research.panasonic.com>]

[Aside: James, your mail made it to the archive without my
intervention, so I guess Dan (the mailing list manager) fixed
the issue]

Hi James.

There is currently no text about default router reachability in
draft-ietf-dna-protocol, but there is in draft-ietf-dna-hosts.
I think your text here would also help to rectify the issue
with multi-link subnets too (although that isn't explicitly
in DNA's existing remit).

We'll have a good think about this particular issue and its
implications for non NetLMM hosts.  WG, Please comment on the
idea's technical merits on list.

The document structure needs to be worked out so that it's
straight forward and this sort of confusion (the proto document
doesn't say, etc...) doesn't happen.  So I don't know which
document this should actually go to yet though

Let's work the structural issues out in a separate thread though.

Greg

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