Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 18 Feb 2005 14:31:54 -0500

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-masked] [mailto:[email-masked]]On 
 > Behalf Of
 > Christian Vogt
 > Sent: Friday, February 18, 2005 1:17 PM
 > To: [email-masked]
 > 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-masked]
 > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
 > --------------------------------------------------------------------
 > 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Greg Daley <[email-masked]>
Date: Sat, 19 Feb 2005 13:19:00 +1100

Hi Hesham,

> a LLA then it responds with a (two options): 

Putting things in STALE doesn't work unless there's a link-layer
address known ( and there's none in the received RS).

> I think the second option might be better to allow for ODAD to

This was discussed recently on DNA list since there's an idea to
use TSLLAOs (Tentative source link-layer address options) in
RSs without SLLAOs when a node is optimistic.

I believe that Erik indicated multicast was the logical way to go.
I guess that's the way most implementations have gone.

We already have at least one implementation (RADVD on linux)
which will send a unicast RA without needing an existing neighbour
entry (and works without SLLAO in RS).  It first does neighbour
resolution before delivering the unicast RA.

Where the NS is sent, the recipient has to respond with an NA
before the RA is sent, so there's no real potential for
multiplicative attacks (except for NS retries when a node isn't
present).

Bandwidth utilization and packet loss probability are higher though.

Greg

---

From: Christian Vogt <[email-masked]>
Date: Sat, 19 Feb 2005 17:57:30 +0100

Hi Hesham, Greg.

> Soliman, Hesham wrote:
>> 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. [...]

> address known ( and there's none in the received RS).

Greg is correct.  When a node has a packet for a neighbor for which the
NC entry is STALE, it does send the packet (trial and error), puts the
entry into DELAY, and waits a while for upper-layer reachability
confirmation.  If the node receives reachability confirmation, then the
entry goes back to REACHABLE.  Otherwise it goes to PROBE, and the
active part of NUD begins (i.e., the node starts transmitting NS's for
the neighbor).

As far as I see it, there is currently no state defined in RFC
2461[bis], except INCOMPLETE, that is appropriate for a NC entry without
link-layer address.  And INCOMPLETE has the additional semantics that
address resolution is in progress.

I guess this is why FreeBSD introduces a new state, NOSTATE.  It does
not do immediate address resolution on an entry in this state.  It
doesn't need to, because Rtadvd (on FreeBSD) sends multicast RA's in all
cases except for ISATAP interfaces.  When a packet is eventually to be
transmitted for an entry in NOSTATE, that entry just moves to INCOMPLETE
and a NS is sent.

The question is whether keeping entries in an additional state makes a
lot of sense.  The approach is more conservate, though, than doing
address resolution rightway (which is how things are done in Linux
according to Greg).

If an RS contains a TSLLAO [1], the router does not have to immediately
initiate address resolution (i.e., be conservative), but can still send
a unicast RA.

> Soliman, Hesham wrote:
>> [...]                      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.

Hesham, why would a multicast RA be required for ODAD?  An optimistic 
node can always send a RS from the unspecified source address to have 
the router multicast the RA.

Unicast RA's could be advantageous on link layers with acknowledgements, 
like IEEE 802.11, where they are realiably transmitted.

- Christian

[1] draft-daley-ipv6-tsllao-01.txt