Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#22 closed defect (fixed)

Multicast IPv6 ND triggers do not provide MN with confirmation of MAP registration success/failure.

Reported by: julien.ietf@… Owned by: julien.ietf@…
Priority: major Milestone:
Component: draft-ietf-netlmm-mn-ar-if Severity:
Keywords: Cc: netlmm@…

Description

There is a problem for the MNs NUD procedure. Suppose the MN tries to register multiple addresses with the MAP and some registrations fail while others succeed. The MN will not receive indication of the failures, since its registration mechanism (NS(DAD)) only receives negative acknowledgements. Then, when the MN tries to send packets using a source address that failed to register with the MAP, the neighbor cache entry will cycle through the states until it reaches the PROBE state at which point the MN sends NS(NUD) to the AR. The NS(NUD) will use as source address an address from the interface which may not be the same as the source address for which communications is failing (since the NCE is keyed on the neighbors on-link unicast address; not the MNs source address). The AR will receive the NS(NUD) and respond with a solicited NA, and the MN will put its NCE back in the REACHABLE state. The cycle will continue indefinitely, and the MNs packets will go into a black-hole.

It seems the only fix for this is for the MN to have a positive indication from the MAP that its address registration succeeded.

Proposed Resolution: No text change. The only possibility of MAP registration failure is 1) MN tries to use a duplicated address and 2) AR cannot reach the MAP because the network is broken. Regarding 1) the MN would get a proxied NS defending the duplicate addresses from the MN [DAD in RFC2462]. Regarding 2) On a regular RFC2461 link, neighbor discovery does not provide MN with a confirmation that the AR it is using is really connected to the rest of the internet. There does not seems to be any difference with that in the NetLMM case.

Change History (4)

comment:1 Changed 13 years ago by julien.ietf@…

  • Cc netlmm@… added

comment:2 Changed 13 years ago by julien.ietf@…

  • Status changed from new to assigned

comment:3 Changed 13 years ago by julien.ietf@…

  • Cc netlmm@… added; netlmm@… removed
  • Resolution set to fixed
  • Status changed from assigned to closed
Christian Vogt wrote:
> Proposed solution:  Use the RS/RA exchange also for the initial
> registration with the NETLMM domain.  The RA is then a positive
> acknowledgment by means of which packet loss can be detected.  I
> did not look carefully into this, but it seems that there is no
> reason why the MN could not use DNA during the initial
> registration.  (Draft draft-ietf-netlmm-mn-ar-if-01.txt currently
> differentiates between the initial attachment and subsequent
> handoffs.)

Julien Laganier replied:
> I think you are referring to subsection 2.1 and included figures. This
> section, and all other subsection of Section 2. do not contain
> normative text and are intended as example of how it works. The
> normative text is in section 3 and 4. So the solution you propose is
> actually already covered by subsection 4.2.2. "Receiving All Others
> ND Messages" as cited above. The signed RA would trigger a NetLMM
> UPDATE.

Christian then replied:
>
> I now understand that the protocol proposed in the draft will also
> leverage a signed RS.  But this leaves us with issue #23 that you
> mentioned in the tracker--- namely, that multiple on-link ARs (or
> MAGs) would register the same MN simultaneously.

Resolution of the issue: no text change. A DNA MN would get a 
confirmation of MAP registration as described in the draft; namely, 
it has to send an RS to detect network attachment. If it then receives
an RA that means that registration was successful.

comment:4 Changed 12 years ago by anonymous

  • Milestone milestone1 deleted

Milestone milestone1 deleted

Note: See TracTickets for help on using tickets.