#126: Short MAC address collision
--------------------------------+-------------------------------------------
Reporter: z...@… | Owner: sami...@…
Type: defect | Status: assigned
Priority: major | Milestone:
Component: nd | Version:
Severity: - | Keywords:
--------------------------------+-------------------------------------------
Changes (by sami...@…):
* status: new => assigned
Comment:
Other solutions proposed/considered:
3. Add "error-to" address field in the ARO between 6LN and 6LR
4. Add a separate option “Multiple Address verification” option
o It is used when one wants to verify the second or third addresses
besides the unique addr
o It is optional and does not require any change in the existing
default behavior
Analysis: We identified along with the working group that the main issue
is being able to return the DAD duplicate NA error-status to the uniquely
identifiable address when conflicting MAC-16 addresses are used on the
same link.
The authors carefully considered all the above options for solving the
above problem and also we looked into minimal change in the document as we
are pretty close to the last call. Also we considered applicability of
SEND on ND if we applied each solution. Adding a separate ICMP message
type for multihop-DAD was another consideration we discussed.
The conclusion is a combination of "Error-to" and Colin's proposal to use
EUI-64 in the ARO to send the error-status back to the conflicting node.
In this case, only change in the document and code is to handle the error
case in NA status field when NS-registration request is made. This is true
for both multihop and single hop address registration.
Solution:
Address registration errors are not sent back to the source address
of the NS due to a possible risk of L2 address collision. Instead
the NA is sent to the link-local IPv6 address with the IID part
derived from the EUI-64 field of the ARO as per [RFC4944]. In
particular, this means that the universal/local bit needs to be
inverted. The NA is formatted with a copy of the ARO from the NS,
but with the Status field set to indicate the appropriate error.
Acknowledgement: Thanks to Colin for helping with the solutions and
providing some message examples for next revision of the 6lowpan-nd draft.
--
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/126#comment:1>
6lowpan <http://tools.ietf.org/6lowpan/>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
