Christian, Thanks for the detailed description. I think Nick brought this up some time ago too.
My suggestion is that upon reception of an RS with no SLLAO the router checks if an entry already exists, if none exists then it creates one and puts it in STALE. If an entry already exists with a LLA then it responds with a (two options): - unicast RA unless a multicast RA was already scheduled. - A multicast RA. I think the second option might be better to allow for ODAD to work. Thoughts? Hesham > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of > Christian Vogt > Sent: Friday, February 18, 2005 1:17 PM > To: [email protected] > Cc: Mark Doll; Roland Bless > Subject: RFC 2461[bis]: RS with srcaddr but w/o SLLAO > > > Hi everybody. > > I have one question regarding IPv6 Neighbor Discovery: What happens > when a router receives a RS with a valid (possibly tentative) source > address, but no SLLAO is included? > > This can happen, for instance, with ODAD, where a host with > a tentative > address may want to solicit a RA with the tentative address. > Section > 3.2 (Modifications to RFC-mandated behaviour --> > Modifications to RFC > 2461 Neighbor Discovery) of > draft-ietf-ipv6-optimistic-dad-05.txt says: > > [...] > * (modifies 6.3.7) A node MUST NOT send a Router > Solicitation with a > SLLAO from an Optimistic Address. Router > Solicitations SHOULD > be sent from a non-Optimistic or the Unspecified Address, > however they MAY be sent from an Optimistic Address > as long as > the SLLAO is not included. > [...] > > IMO, neither RFC 2461 nor RFC 2461bis is clear on what a > router should > do in this case. RFC 2461, section 6.2.6 (Router and Prefix > Discovery > --> Processing Router Solicitations) says: > > [...] > Router Solicitations in which the Source Address is the > unspecified > address MUST NOT update the router's Neighbor Cache; > solicitations > with a proper source address update the Neighbor Cache > as follows. If > the router already has a Neighbor Cache entry for the > solicitation's > sender, the solicitation contains a Source Link-Layer > Address option, > and the received link-layer address differs from that > already in the > cache, the link-layer address SHOULD be updated in the > appropriate > Neighbor Cache entry, and its reachability state MUST > also be set to > STALE. If there is no existing Neighbor Cache entry for the > solicitation's sender, the router creates one, installs the link- > layer address and sets its reachability state to STALE > as specified > in Section 7.3.3. Whether or not a Source Link-Layer > Address option > is provided, if a Neighbor Cache entry for the > solicitation's sender > exists (or is created) the entry's IsRouter flag MUST be set to > FALSE. > [...] > > The first "If..." doesn't hold because the SLLAO is assumed > not to be > included in the RS. The second "If..." actually holds, but > states that > the router "installs the link-layer address and sets its > reachability > state to STALE". Well, but what is to be done when we do > not have the > SLLAO? Does the router need to look up the source address > from the MAC > header? And if it does not and leaves the link-layer address empty, > which state should it put the new NC entry in? RFC > 2461[bis] doesn't > seem to have a state appropriate for this situation. > (FreeBSD actually > uses its own state; more on this further down.) > > The part of section 7.3.3 (NUD --> Node Behavior) which the > above text > refers to is IMO the following: > > [...] > A Neighbor Cache entry enters the STALE state when created as a > result of receiving packets other than solicited Neighbor > Advertisements (i.e., Router Solicitations, Router > Advertisements, > Redirects, and Neighbor Solicitations). These packets > contain the > link-layer address of either the sender or, in the case > of Redirect, > the redirection target. However, receipt of these link-layer > addresses does not confirm reachability of the > forward-direction path > to that node. Placing a newly created Neighbor Cache > entry for which > the link-layer address is known in the STALE state > provides assurance > that path failures are detected quickly. In addition, should a > cached link-layer address be modified due to receiving one of the > above messages the state SHOULD also be set to STALE to provide > prompt verification that the path to the new link-layer > address is > working. > [...] > > Similar to the first extract, this one seems to assume that > a SLLAO is > always provided in an RS. So a newly created entry should > be put into > STALE state. But if there is no link-layer address, then the STALE > state doesn't make much sense. The router might attempt to send a > packet to that unspecified link-layer address as part of the > NUD process. > > RFC 2461bis doesn't clarify these things. I might be wrong, > but I think > there is some inconsistency in RFC 2461bis. > > By the way, FreeBSD 5.3 kind of gets around this issue by using an > additional NC-entry state, NOSTATE, for new entries for which the > link-layer address is unknown. When a packet is to be forwarded (or > send) to some neighbor, and the NC has an entry labeled > NOSTATE, that > entry is put into state INCOMPLETE and address resolution > begins as usual. > > As far as I can see, the additional state is needed if a > router actually > creates a NC entry upon receiving a RS without SLLAO. An > alternative > would be not to create the NC entry. But this may not be > appropriate on > links layers without source addresses... > > Kind regards, > > - Christian > > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ > > "No great genius has ever existed without some touch of > madness." (Aristotle) > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
