Subject: Clarify NA processing

From: Markku Savela <[email-masked]>
Date: Mon, 17 Dec 2001 23:47:58 +0200

I've had some problems getting the ND right, especially the IS ROUTER
bit handling in some cases. The RFC has some long winded convoluted
english statements with and's and or's, that I have hard time
parsing. The state table in the appendix is also somewhat hard to
read, and does not cover all combinations.

So to clarify my thoughs, I decided to construct a new table, this one
just for Neighbor Advertisement. I would now like verify that I got it
right and have couple of questions too.

----------------------------
Neighbor Advertisement info:

  No TLL, TLL present
  s = unsolicited (S=0), S = solicited (S=1)
  o = no override (O=0), O = override set (O=1)

Actions:

 STALE   the new state of cache entry
 REACH   the new state of cache entry
   -     no chance in cache entry
addr=TTL address of the entry is updated
   R     router bit is processed (R=0 host, R=1 router)
   ?     Don't know what should be done

=========================================================================
First link layer without addresses:
=========================================================================
          |     No TLL given            |    TLL given
STATE     | s,o  | s,O  | S,o   | S,O   | s,o   | s,O    | S,o   | S,O
----------+------+------+---------------+----------------+-------+-------
= INCOMPL |    STALE    |    REACH      |                |
No Address|      R      |      R        |       ?        |       ?
----------|-------------|---------------|-------+--------|-------+-------
REACHABLE |   -  |  -   | REACH | REACH |       |        |       |
No Address|   R  |  R   |   R   |   R   |   ?   |   ?    |   ?   |    ?
----------|------|------|-------|-------|-------|--------|-------|-------
OTHER     |   -  |  -   | REACH | REACH |       |        |       |
No address|   R  |  R   |   R   |   R   |   ?   |   ?    |   ?   |    ?
=========================================================================

   Question: What should I do with NA that gives TLL on a link that is
   not using link layer addresses? (the "?" marks). Alternatives are

   a) ignore as invalid
   b) ignore the TLL option as if it wasn't present, and process as
      described on the left side.

Following with Link Layer that uses address:
=========================================================================
          |     No TLL given            |    TLL given
STATE     | s,o  | s,O  | S,o   | S,O   | s,o   | s,O    | S,o   | S,O
----------+------+------+---------------+----------------+-------+-------
= INCOMPL |      -      |       -       |   addr=TLL     |    addr=TLL
          |      -      |       -       |     STALE      |     REACH
          |      -      |       -       |       R        |       R
----------|-----------------------------|-------|--------|---------------
!= INCOMPL|                             |   -   |   -    |   -   |    -
Address   | N/A (no TLL, cannot be same)|   -   |   -    | REACH |  REACH
  == TLL  |                             |   R   |   R    |   R   |    R
----------|-----------------------------|-------|--------|-------|--------
REACHABLE |   -  |  -   |   -   |   -   |   -   |addr=TLL|   -   |addr=TLL
Address   |   -  |  -   |   -   |   -   | STALE | STALE  | STALE | STALE
  =! TLL  |   -  |  R?  |   -   |   R?  |   -   |   R    |   -   |    R
----------|-----------------------------|-------|--------|-------|--------
OTHER     |   -  |  -   |   -   |   -   |   -   |addr=TLL|   -   |addr=TLL
Address   |   -  |  -   |   -   |   -   |   -   | STALE  |   -   | STALE
  =! TLL  |   -  |  R?  |   -   |   R?  |   -   |   R    |   -   |   R
==========================================================================

   Question: Concerning the lower left corner section: NA doesn't give
   TLL, even if link is using addresses (here treated as Address !=
   TLL), but neighbor cache entry exists.

       - what should happen? Ignore always? Or ISROUTER bit handling
	 supposed to happen for these (for example, those marked with
	 "R?")

-- 
Markku Savela <[email-masked]>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Wed, 19 Dec 2001 14:44:24 +0200

in "4.Access to IPv6 and Extension Headers" there is

--------
   First, to receive any of this optional information (other than the
   next hop address, which can only be set), the application must call
   setsockopt() to turn on the corresponding flag:

       int  on = 1;

       setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO,  &on,
       sizeof(on));
       setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on,
       sizeof(on));
       setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR,    &on,
       sizeof(on));
       setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS,  &on,
       sizeof(on));
       setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS,  &on,
       sizeof(on));
       setsockopt(fd, IPPROTO_IPV6, IPV6_RECVTCLASS,   &on, sizeof(on));
---------

I have said it before, but I repeat it once more: above is wrong
design because:

   - api has to be redefined every time a new extension header is
     introduced,

   - and if that extension header can appear in multiple places, you
     have to define multiple options for each possible combination.

A much better API would be some definition similar to "struct
icmp6_filter", which would use the protocol numbers.

If a header occurs multiple times, application would receive all of
them.

If application needs to care whether some header occurs before
another (like DST OPT before Routing), then it would ask both and it
can easily find out what it needs (and for common case, like dstopt
vs. routing, a small library routine might be provided).

---

From: Markku Savela <[email-masked]>
Date: Wed, 19 Dec 2001 14:54:41 +0200

> From: Markku Savela <[email-masked]>

Ok, I posted sloppily, as defined it's not as bad as I thought, the
destopt before/after routing option has been removed. Good.

>        setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR,    
>        setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS,
>        setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS,

..and I pasted other than just extension header options. However, I
still question, whether the filter way of specifying them would be
a more robust solution.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 19 Dec 2001 15:06:15 +0100

In your previous mail you wrote:
   
   I've had some problems getting the ND right, especially the IS ROUTER
   bit handling in some cases.

=> the is_router flag is in fact very easy: if the NA is valid
you take it and you get the transition table (I note u (unkown)
the bottom semantical value, with R and H):
 u -> H, u -> R: just note it
 u -> u, H -> H, R -> R: nothing to do
 H -> u, R -> u: should not happen (this is the effect of
  a cache flush on timeout, not of the reception of a NA)
 H -> R: uncommon but just note it
 R -> H: the router is no more a router, flush it from the default
  router list, etc (i.e. same than a router becomes unreachable).
Note that RSs and RAs can change the is_router bit too because
only hosts may send RSs and only routers may send RAs.
The Target Link-Layer address has nothing to do with the is_router
bit but this bit makes the usage of a router recommended for anycasts
(i.e. its value should be stable). In some circumstances the TTL
is mandatory too (i.e. without it the NA is invalid and must be
silently dropped), of course never on links without link-layer
addresses (as most of IPv6 over IPv4 tunnels).
IMHO this is a good practice to put the S/TLL when it is not explicitely
forbidden in neighbor discovery messages.

Regards

[email-masked]

---

From: Markku Savela <[email-masked]>
Date: Wed, 19 Dec 2001 17:16:57 +0200

> From: Francis Dupont <[email-masked]>

I don't have any "UNKNOWN" R/H state. It's either a host or a
router. And, initial value is always HOST.

>  H -> u, R -> u: should not happen (this is the effect of

I don't have problem with what to do when transition R->H or H->R
happens. The problem is how I detect this transition with certain
class of Neigbor advertisements, specifically those that omit target
link layer address. Do I process the R bit or not?

In RFC-2461, section 7.2.5, there is quite complex sentence (for
me)...
                     .....If the Override flag is clear and the
 supplied link-layer address differs from that in the cache, then one
 of two actions takes place: if the state of the entry is REACHABLE,
 set it to STALE, but do not update the entry in any other way;
 otherwise, the received advertisement should be ignored and MUST NOT
 update the cache.  If the Override flag is set, both the Override
 flag is clear and the supplied link-layer address is the same as that
 in the cache, or no Target Link-layer address option was supplied,
                  ======================================   
 the received advertisement MUST update the Neighbor Cache entry as
 follows: ...

So, depending on how you bind the  or in ", or no Target", you may
get different implementations.

That's why I made the table (which I hope is clearer than above text)
and wanted have a definite answer. So, this is the correct left corner
then

....
  =! TLL  |   -  |  -   |   -   |   -   |   -   |   R    |   -   |    R
  =! TLL  |   -  |  -   |   -   |   -   |   -   |   R    |   -   |   R

That is, if link layer is using addresses, ignore Neighbor
advertisements without TLL totally?

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 20 Dec 2001 02:18:39 +0900

>>>>> On Wed, 19 Dec 2001 14:54:41 +0200, 
>>>>> Markku Savela <[email-masked]> said:

> still question, whether the filter way of specifying them would be

In terms of the notion of generalization, it might be better to use a
same type of array as icmp6 filter.  However, I don't see much benefit
of it from a practical point of view.  In fact, it is harder to
introduce a new extension headers than to introduce a new ICMPv6 type
(there was actually a discussion on this topic in this list, in a
different context).  Additionally, I'm not really sure if an
application wants to receive such new extension headers for a
practical purpose, while new types of ICMPv6 messages will tend to be
handled in the application layer.  For minor usage, we've already had
perfectly generic mechanisms such as BPF and DLPI.

So..., sorry, but I won't change the current spec unless we have a
concrete and practical example of such new extension header types and
applications that want to receive the headers.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Wed, 19 Dec 2001 20:08:36 +0100

I don't have any "UNKNOWN" R/H state.

=> this is not a state, this is the bottom semantical value,
i.e. the absence of a state.

=> if there is a TLL and TLL is forbiden or if there is no TLL
and TLL is mandatory then the NA is not valid and the R bit must not
be processed. Else the NA is valid and the R bit must be processed.
I believe your problem is more with validity checking than with the R bit.

    update the cache.

=> this is a invalidity (sp?) statement. You have the explicit term "ignore".

    If the Override flag is set, both the Override

=> this is about the TLL, in any case the NA is valid and the R bit
must be processed.

=> no, ignore them for the link-layer address of the neighbor,
NOT for the R bit.

Regards

PS: you can try to understand the logic of the whole stuff too,
this is a simple state automaton.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Wed, 19 Dec 2001 21:25:54 +0200

> => if there is a TLL and TLL is forbiden or if there is no TLL and
> TLL is mandatory then the NA is not valid and the R bit must not be
> processed. Else the NA is valid and the R bit must be processed.  I
> believe your problem is more with validity checking than with the R
> bit.

Ok, but here is the problem: where in RFC-2461 this is stated? My
whole problem starts with this, there is no clear wording about
this. (Nor there is any mention about mandatory vs. non-mandatory
TLL).

There is specific section "7.1.2 Validation of Neighbor
Advertisements", and this specifies "valid advertisement". There no
word about NA being invalid depending on presence of TLL or not.

OK, this is all nitpicking, RFC needs just minor addition into
7.1.2:

 - if link uses addresses, then NA MUST have TLL.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Dec 2001 11:16:11 +0100

Ok, but here is the problem: where in RFC-2461 this is stated?

=> section 4.4 page 24.

   Nor there is any mention about mandatory vs. non-mandatory TLL

=> idem
   
   There no word about NA being invalid depending on presence of TLL or not.

=> idem

   
=> NO, the MUST is in section 4.4 page 24. There is an explanation too...
The only not written detail is that a NA which doesn't comply with a MUST
is not valid, i.e. 7.1.2 is too brief.

Regards

PS: I've checked, the correct adjective for a semantic thing is semantic
(not semantical).