#86: SLLA/TLLA clarification
--------------------------------+-------------------------------------------
Reporter: z...@… | Owner: z...@…
Type: defect | Status: new
Priority: major | Milestone:
Component: nd | Version:
Severity: - | Keywords:
--------------------------------+-------------------------------------------
ZigBee IP noticed that some clarifications are needed around the use of
SLLA in the document, and wondered if TLLA should be used in some places.
The authors looked into the issue and currently have the following
suggestions:
1. As the LLA is not really used for anything in the NA, there is no
reason to carry a LLA there, TLLA is actually not required in the draft at
all. This should be better documented and Figure 3 fixed. In particular:
For 6lowpan-nd we could say in section 6.5.2 after
The Registration Lifetime and the EUI-64 are recorded in the Neighbor
Cache entry. A unicast Neighbor Advertisement (NA) is then sent in
response to the NS. This NA SHOULD include a copy of the ARO, with the
Status field set to zero.
that "A TLLA option is not required in the NA, since the host already
knows the router's link-layer address from Router Advertisements."
2. Section 5.4 currently says "Furthermore, the SLLA option MUST be
included in the RS." This is a bug and should say RA instead of RS.
3. There may also be some confusion on the carrying of LLAs in multihop
DAD NS/NA exchanges. In this case BOTH the NS and NA MUST carry an SLLA
option.
--
Ticket URL: <http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/86>
6lowpan <http://tools.ietf.org/6lowpan/>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
