Subject: [DNA] Re: Test, please ignore

From: Greg Daley <[email-masked]>
Date: Tue, 28 Mar 2006 18:44:07 -0500

Hi James, I got the direct one.

I'll look for the other.

----- Original Message -----
From: James Kempf <[email-masked]>
Date: Tuesday, March 28, 2006 5:09 pm
Subject: Test, please ignore
To: Dna <[email-masked]>
Cc: Gregory Daley <[email-masked]>

---

From: Greg Daley <[email-masked]>
Date: Wed, 29 Mar 2006 15:35:26 -0500

[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.
> 
> 
> 
>

---

From: Christian Vogt <[email-masked]>
Date: Thu, 30 Mar 2006 00:56:24 -0600

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:

>  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:
>
> router in order to confirm bidirectional reachability. Bernard
> Abboba's draft on architectural link indications:
>
> 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.
>  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
>
> section after Section 5.2.5.1.
>
> 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.
>
> 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
> 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

---

From: Christian Vogt <[email-masked]>
Date: Fri, 31 Mar 2006 12:53:31 -0600

Hi James.

> RFC 2641 says this in Section 6.3.6:
> 
>     1) Routers that are reachable or probably reachable (i.e., in any
>        state other than INCOMPLETE) SHOULD be preferred over routers
>        whose reachability is unknown or suspect (i.e., in the
>        INCOMPLETE state, or for which no Neighbor Cache entry exists).
>        An implementation may choose to always return the same router or
>        cycle through the router list in a round-robin fashion as long
>        as it always returns a reachable or a probably reachable router
>        when one is available.
> 
> So, in effect, this proposal is to tighten the definition up.

Certainly.  I meant to say that the tighened definition actually belongs
into RFC2461bis, rather than into the DNA protocol, and should be
updated there IMO.  But it won't really make a difference in the end
anyway, and the IPv6 WG might be unwilling to modify RFC2461bis yet
another time at this stage.

> To really accelerate router selection, the following needs to be added:
> 
> (f) In order to reduce the delay in achieving IP connectivity, reset the
> chosen default router to the router in the first RA received after the
> RS is sent.

This should come as a natural consequence of (a) through (e):  After
step (b), all router entries in the NC are in STALE state.  Hence, since
the MN obeys (e) "at all times", it will reset its default router
immediately after receiving the first RA, because the NC entry for that
default router will be the only one in REACHABLE state.

When the MN received more RAs, it won't change its default router again,
because its current default router is already in REACHABLE state.

> OK.
> Any objections from other WG members to modifying the text I sent to
> incorporate Christian's changes?

- Christian