[Top] [All Lists]

IPv6: NS -> NA reply RFC2461 SHOULD considerations [patch]

To: <netdev@xxxxxxxxxxx>
Subject: IPv6: NS -> NA reply RFC2461 SHOULD considerations [patch]
From: Pekka Savola <pekkas@xxxxxxxxxx>
Date: Thu, 3 May 2001 15:53:08 +0300 (EEST)
Cc: <usagi-users@xxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx

RFC2461, 4.4:
      O              Override flag.  When set, the O-bit indicates that
                     the advertisement should override an existing cache
                     entry and update the cached link-layer address.
                     When it is not set the advertisement will not
                     update a cached link-layer address though it will
                     update an existing Neighbor Cache entry for which
                     no link-layer address is known.  It SHOULD NOT be
                     set in solicited advertisements for anycast
                     addresses and in solicited proxy advertisements.
                     It SHOULD be set in other solicited advertisements
                     and in unsolicited advertisements.

      Target link-layer address
                     The link-layer address for the target, i.e., the
                     sender of the advertisement.  This option MUST be
                     included on link layers that have addresses when
                     responding to multicast solicitations.  When
                     responding to a unicast Neighbor Solicitation this
                     option SHOULD be included.

                     The option MUST be included for multicast
                     solicitations in order to avoid infinite Neighbor
                     Solicitation "recursion" when the peer node does
                     not have a cache entry to return a Neighbor
                     Advertisements message.  When responding to unicast
                     solicitations, the option can be omitted since the
                     sender of the solicitation has the correct link-
                     layer address; otherwise it would not have be able
                     to send the unicast solicitation in the first
                     place. However, including the link-layer address in
                     this case adds little overhead and eliminates a
                     potential race condition where the sender deletes
                     the cached link-layer address prior to receiving a
                     response to a previous solicitation.

Linux is does not seem to fulfull these recommendations.  These seem to
affect USAGI too.

1) When soliciting for anycast address, override flag in the reply SHOULD
NOT be set.  This may happen under certain circumstances.  Proxy
advertisements are already handled as recommended.

There doesn't seem to be any checks for anycast in ndisc yet.. Probably
not too supported yet.

2) In neighbor solicitations to unicast addresses, lladdr is not added to
the router advertisement.

Adding lladdr could probably be always done, except when L2 medium
doesn't have lladdr.  The only downside here is added space requirements
(see above for discussion) which are IMO negligible.

Warning: the patch has not been tested extensively, but compiles and
doesn't seem to cause too major side effects. Double check for
sanity / better way to do it.

Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

Attachment: ndisc-na_ns.patch
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>