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

From: Christian Vogt <[email-masked]>
Date: Fri, 18 Feb 2005 19:16:37 +0100

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

---

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 18 Feb 2005 22:21:15 -0500

Hi Greg, 

I was definitely assuming that address resolution will
take place in the case where the response is sent unicast.
I assume that's what you're suggesting, but I'm not sure what
state you're suggesting.

Hesham

 > -----Original Message-----
 > From: Greg Daley [mailto:[email-masked]]
 > Sent: Friday, February 18, 2005 9:19 PM
 > To: Soliman, Hesham
 > Cc: Christian Vogt; [email-masked]; Mark Doll; Roland Bless
 > Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO
 > 
 > 
 > Hi Hesham,
 > 
 > 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. If an entry already exists with
 > > 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).
 > 
 > > - 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?
 > 
 > 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
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

---

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

Hi Hesham, 

----- Original Message -----
From: "Soliman, Hesham" <[email-masked]>
Date: Saturday, February 19, 2005 2:21 pm
Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO

> I assume that's what you're suggesting, but I'm not sure what

There's no state created (no NCE) until the unicast packet
is about to be sent.

this ensures that NCEs aren't created for RSs arriving 
without SLLAO which receive a multicast response.

This is exactly as it should be.

Greg

---

From: "Soliman, Hesham" <[email-masked]>
Date: Sat, 19 Feb 2005 18:17:54 -0500

Folks, 

Just to make sure this issue is addressed, I think we can allow
routers to either respond with a unicast or multicast RA in the 
case where an RS without SLLAO is received. It seems like there 
are different cases where multicast would make more
sense than unicast (or at least implementers chose to do so) and 
vice versa. So, unless someone sees a need to mandate a certain 
response, I think we should allow both behaviours. If there are no 
objections I'll add that to the draft.

Obviously in the case of unicast RA, address resolution will take
place first, resulting in the creation of an NCE. If multicast RA, then
there will be no need for address resolution or creating NCE.

Hesham

 > From: [email-masked] [mailto:[email-masked]]On 
 > Behalf Of
 > Christian Vogt
 > Sent: Saturday, February 19, 2005 11:58 AM
 > To: [email-masked]; Soliman, Hesham
 > Cc: Mark Doll; Roland Bless; [email-masked]
 > Hi Hesham, Greg.
 > >> 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. [...]
 > 
 > Greg Daley wrote:
 > 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
 > 
 > --

---

From: "Soliman, Hesham" <[email-masked]>
Date: Sun, 20 Feb 2005 18:55:17 -0500

ok thanks.

 > Sent: Sunday, February 20, 2005 6:53 PM
 > To: Soliman, Hesham
 > > The text now looks like this:
 > > 
 > > in Section 7.3.3. If there is no existing Neighbor Cache 
 > entry and no
 >  > Source Link-Layer Address option was present in the 
 > solicitation, the
 >  > router may respond with either a unicast or a multicast router
 > > advertisement. Whether or not a Source Link-Layer Address option
 > > I hope this is clear, if not let me know ASAP because I'm 
 > submitting
 > > the draft soon before the deadline.
 > 
 > It's OK.
 > 
 > If you wish to swap the 'unicast or multicast' in the second last
 > sentence to 'multicast or unicast', then that will reflect today's
 > default preference order.
 > 
 > Greg
 > 
 > > Hesham
 > > 
 > > 
 > >  > Sent: Sunday, February 20, 2005 6:13 PM
 > >  > To: Christian Vogt
 > >  > Cc: Soliman, Hesham; [email-masked]; Mark Doll; Roland Bless
 > >  > Hi Christian and Hesham,
 > >  > I think people are asymptoting to the
 > >  > same point.
 > >  > 
 > >  > Are we supposed to be suggesting text though?
 > >  > 
 > >  > Christian Vogt wrote:
 > >  > > Hi Hesham.
 > >  > > 
 > >  > >  > [...]
 > >  > > 
 > >  > >>  > doesn't need to, because Rtadvd (on FreeBSD) sends 
 > >  > multicast  > 
 > >  > >> RA's in all
 > >  > >>  > cases except for ISATAP interfaces. 
 > >  > >> => Right, I was trying to accomodate other ways of 
 > >  > implementing Rtadvd
 > >  > >> that would send unicast RAs in response to the RS in 
 > question. For
 > >  > >> example in the case where no LLA exists in the 
 > technology used. In
 > >  > >> this case it would be wasteful to multicast the RA. This 
 > >  > is especially
 > >  > >> true in a mobile system where you might get several 
 > RSs due to MNs
 > >  > >> appearing on the link.
 > >  > > 
 > >  > > 
 > >  > > I agree.
 > >  > > 
 > >  > >> [...]
 > >  > >> => So, from the above, I assume you suggest that we 
 > always send a 
 > >  > >> multicast RA in response? I don't know if this is a good way
 > >  > >> to go given the example I mentioned above. What do you think?
 > >  > > 
 > >  > > 
 > >  > > No, I don't think that a RA should always be muticasted.  
 > >  > It certainly 
 > >  > > makes sense in many situations to unicast a RA.  I get 
 > >  > back to this in 
 > >  > > my last comment.
 > >  > > 
 > >  > >>  > 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.
 > >  > >>
 > >  > >> => I think the TSLLAO draft is useful in this case, but 
 > >  > we obviously
 > >  > >> still need to address this case for legacy hosts that 
 > >  > don't implement
 > >  > >> TSLLAO.
 > >  > > 
 > >  > > 
 > >  > > Ok.
 > >  > > 
 > >  > >>  > > Soliman, Hesham wrote:
 > >  > >>  > >>  > >> 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.
 > >  > >>
 > >  > >> => That's true, I didn't consider this case. It's been a long
 > >  > >> time since I last read ODAD and I don't know if it allows 
 > >  > the Onode to 
 > >  > >> send RSs with a tentative src address or if it
 > >  > >> requires the unspecified address. I guess it should 
 > just use the 
 > >  > >> unspecified address while the unicast one is tentative.
 > >  > > 
 > >  > > 
 > >  > > An optimistic node may use a tentative source address in a 
 > >  > RS.  But if 
 > >  > > it does, it must not include the SLLAO.  This prevents the 
 > >  > router from 
 > >  > > overwriting a possibly existing NC entry for the tentative 
 > >  > address's 
 > >  > > real owner.
 > >  > > 
 > >  > > For the same reason, the optimistic node cannot use a 
 > >  > SLLAO in a NS sent 
 > >  > > from a tentative source address.  But since a NS does not 
 > >  > make a lot of 
 > >  > > sense without a SLLAO, a NS cannot be sent at all 
 > from a tentative 
 > >  > > source address.  So it must always be the router or a 
 > neighbor who 
 > >  > > starts address resolution for an optimistic node while the 
 > >  > optimistic 
 > >  > > node's is still tentative.
 > >  > 
 > >  > This is just as an aside (won't affect the discussion much).
 > >  > It's true that opti-dad isn't allowed to be sent for multicast
 > >  > destinations, where SLLAO must be sent.
 > >  > In unicast NS, where it's not mandatory, it may still 
 > >  > possible to send
 > >  > NS with TSLLAO.  I'm not sure it's useful though.
 > >  > 
 > >  > It's worth noting that responses to unicast NS from a node 
 > >  > which doesn't
 > >  > actually have a valid NCE for the solicitor (it is 
 > assumed to do so,
 > >  > from section 7.2.2 of 2461), NS/NA exchange in the 
 > reverse direction
 > >  > is performed before delivery of the NA.
 > >  > 
 > >  > >>  > Unicast RA's could be advantageous on link layers with  > 
 > >  > >> acknowledgements,  > like IEEE 802.11, where they 
 > are realiably 
 > >  > >> transmitted.
 > >  > >>
 > >  > >> => Sure, there are many other examples of WWANs where unicast
 > >  > >> RAs make more sense when responding to RSs, that's why I'm
 > >  > >> not sure if it's always good to follow the FreeBSD way 
 > >  > you describe
 > >  > >> above.
 > >  > > 
 > >  > >  >
 > >  > >  > It'd be good if we can get some agreement on this 
 > before the
 > >  > >  > draft deadline.
 > >  > > 
 > >  > > Yes, Hesham.  I didn't mean to say that the way FreeBSD 
 > >  > responds to RS's 
 > >  > > is my favorite.  Actually, I think that we now have two 
 > >  > use-cases where 
 > >  > > unicast RS's make more sense, WWANs and 802.11, and there 
 > >  > are probably 
 > >  > > more.  Also, I don't think that the additional state, 
 > >  > NOSTATE, which 
 > >  > > FreeBSD uses for NC entries without L2 addresses makes a 
 > >  > lot of sense.
 > >  > > 
 > >  > > Overall, I think that the plethora of scenarios can be 
 > >  > accommodated best 
 > >  > > if we leave a node some choice with respect to when a 
 > >  > router creates a 
 > >  > > NC entry, and when it sends a RA by unicast or by multicast.
 > >  > > 
 > >  > > RFC 2461bis already depends NC updates on whether the 
 > RS's source 
 > >  > > address is unspecified or not:  If it is unspecified, the 
 > >  > NC is not 
 > >  > > updated.  If it is valid, either an existing NC entry is 
 > >  > modified or a 
 > >  > > new NC entry is created.  I think this is good; maybe we 
 > >  > can expand on 
 > >  > > these rules.
 > >  > > 
 > >  > > (1)  The router can unicast a RA if and only if it 
 > >  > previously received a 
 > >  > > RS with a valid (specified) source address.  Rate 
 > limitations may 
 > >  > > prohibit the router from sending a unicast RA, though, and 
 > >  > instead send 
 > >  > > a multicast RA that is anyway scheduled for transmission.  
 > >  > RFC 2461bis 
 > >  > > already has this functionality.
 > >  > > 
 > >  > > (2)  If the received RS has a valid source address, but no 
 > >  > SLLAO, then 
 > >  > > address resolution must be done before the unicast RA is 
 > >  > sent. [Hmm, one 
 > >  > > may also consider to trigger address resolution, but 
 > still send a 
 > >  > > multicast RA.  This could be faster than the unicast RA, 
 > >  > which would 
 > >  > > have to wait for address resolution to complete...]
 > >  > 
 > >  > It's not really worth it to do address resolution.  That would
 > >  > need to create neighbour cache state, when there's 
 > nothing to send
 > >  > in the neighbour cache entry queue.  The outside the [...]
 > >  > it looks ok.
 > >  > 
 > >  > I'd probably guess that it's worth putting a caveat here:
 > >  > 
 > >  > If there's no SLLAO, some routers may perfer to 
 > schedule a multicast
 > >  > response, in order to avoid neighbour discovery, which 
 > may be costly
 > >  > on some links.
 > >  > 
 > >  > > (3)  The router sends multicast RA's, first, on a periodic 
 > >  > basis and, 
 > >  > > second, whenever it receives a RS with an unspecified 
 > >  > source address. 
 > >  > > According to RFC 2461bis, rate limitations may cause the 
 > >  > router to not 
 > >  > > immediately send a solicited multicast RA, but to wait for 
 > >  > the next 
 > >  > > periodic multicast RA.
 > >  > 
 > >  > 
 > >  > > (4)  Rate limitations should be adjustable according to a 
 > >  > particular 
 > >  > > link-layer technology, capacity, and deployment scenario.  
 > >  > This allows 
 > >  > > for easy optimizations, like [1].
 > >  > 
 > >  > Nothing is easy ;-)
 > >  > 
 > >  > There's work going on with regard to FastRA which may provide
 > >  > the benefits without manual configuration though.  So if this
 > >  > is text we're after, I'd prefer no (informative) references to
 > >  > FastRA in a DS.
 > >  > 
 > >  > It's worth specifying that deployers consult IPv6 over 
 > foo documents
 > >  > or IPv6 network deployment BCPs to see if any recommendations
 > >  > update specifications in this document.
 > >  > 
 > >  > > - Christian
 > >  > > 
 > >  > > [1] draft-mkhalil-ipv6-fastra-05.txt
 > >  > > 
 > >  > 
 > >  > Greg
 > >  > 
 > >