Hi all,

I'd like to ask you about an issue regarding the I-D.ietf-6lowpan-nd. Sections 
3.5 and 6.3 state that 6LRs and 6LBRs MAY create TENTATIVE NCEs when receiving 
Router Solicitations.

Section 3.5:

When a host interacts with a router by sending Router Solicitations

   this results in a Tentative NCE.

Section 6.3
 A Router Solicitation might be received from a host that has not yet

   registered its address with the router.  Thus the router MUST NOT
   modify an existing Neighbor Cache entry based on the SLLA option from
   the Router Solicitation.  However, a router MAY create a Tentative
   Neighbor Cache entry based on the SLLA option.  Such a Tentative
   Neighbor Cache entry SHOULD be timed out in TENTATIVE_NCE_LIFETIME
   seconds unless a registration converts it into a Registered NCE.

According to section 3.3 (Host to Router Interaction), a host only registers 
non-link-local addresses with routers:


 When a host has configured a non-link-local IPv6 address, it
   registers that address with one or more of its default routers using
   the Address Registration option (ARO) in an NS message.

Finally, sections 5.2 (Interface Initialization) and 5.3 (Sending a Router 
Solicitation) specify how RS messages are sent from hosts to Routers:

Section 5.2:

When the interface on a host is initialized it follows the
   specification in [RFC4861<http://tools.ietf.org/html/rfc4861>].  A 
link-local address is formed based on
   the EUI-64 identifier 
[EUI64<http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15#ref-EUI64>] assigned 
to the interface as per
   [RFC4944<http://tools.ietf.org/html/rfc4944>] or the appropriate IP-over-foo 
document for the link, and
   then the host sends Router Solicitation messages as described in
   [RFC4861] Section 6.3.7<http://tools.ietf.org/html/rfc4861#section-6.3.7>.

Section 5.3

Since hosts do not depend on multicast Router Advertisements to
   discover routers, the hosts need to intelligently retransmit Router
   Solicitations whenever the default router list is empty, one of its
   default routers becomes unreachable, or the lifetime of the prefixes
   and contexts in the previous RA are about to expire.

This makes me think that:

(1) The only valid source address a host has at bootstrapping, is the 
link-local address.
(2) Link-local address are not registered with routers
(3) If the default router list is empty, the case is the same that at 
bootstrapping: the only valid address is the link-local address.
(4) When a router becomes unreachable or lifetimes are about to expire, then it 
is likely that the corresponding router already has a NCE for that host.

Due to (1), (2), and (3), the only NCE a router may create shall contain the 
host's link-local address. As this address is not registered (no NS with ARO 
for registration of that address will be sent), the NCE will inevitably expire 
TENTATIVE_NCE_LIFETIME seconds after its creation.

Then, I do not see many situations when the effort of creating TENTATIVE NCEs 
upon arrival of RS messages is worth it. Indeed, as far as I understand, 
multiple factors must occur in order that the creation of the TENTATIVE NCE 
makes sense and it ends up becoming a REGISTERED NCE.

Please, correct me if I am wrong, but I would say that this creation of 
TENTATIVE NCEs is in most cases undesirable and, at least, some clarifications 
regarding it would be required in the draft.

Regards,

Luis Maqueda
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

Reply via email to