[netlmm] RE: Issue #22 (Was: Re: Issues #22 and #23)

["Templin, Fred L" <[e-mail]>]

Julien,

I discussed this in detail with my colleagues at Boeing, and
our conclusion was that there may be issues for control message
loss in certain scenarios (e.g., IEEE 802.11 unreliable multicast)
but the comparative analysis needs to be more balanced (see below).

The main point is that we believe the DHCP approach may be more
widely applicable but the network-based approach may be suitable
for certain use cases, e.g., if the DHCP client is seen as too
much complexity for constrained MNs and the network is robust
enough to avoid control message loss issues.

As such, we believe an applicability analysis and statement for
NETLMM is necessary. Please see below for more details and send
comments.

Fred
[e-mail]

Appendix B.  Control Message Loss Implications for NETLMM

   [I-D.ietf-netlmm-mn-ar-if] specifies a network-based mechanism that
   uses a MN's duplicate address detection procedure to implicitly
   trigger address registration signaling between the AR and the MAP,
   while this document specifies a host-based mechanism that uses a MNs
   DHCP requests to explicitly trigger address registration signaling
   between the MN and the MAP.  Control message loss implications for
   both scenarios are analyzed in the following sections:

B.1.  Implications for Network-Based Signaling

   In the network-based signaling method specified in [I-D.ietf-netlmm-
   mn-ar-if], if the MN configures a tentative address and sends a
   Neighbor Solicitation (NS) message to the solicited-node multicast
   address (see: [RFC2462], Section 5.4.2), but a control message is
   lost somewhere on the MN<->AR<->MAP paths, the MN could incorrectly
   conclude that its tentative address was both unique and successfully
   registered with the MAP.  The following scenarios can occur:

   1.  If the MN's multicast NS message is lost on the MN->AR path, the
       AR will not perform address registration and the MN will receive
       no indication that address registration failed.  The MN will then
       incorrectly assign the tentative address to an interface after
       RetransTimer msecs (see: [RFC2462], Section 5.4).

   2.  If the AR attempts to register a MN's tentative address with the
       MAP and the MAP returns an indication that the address was a
       duplicate, the AR will defend the MN's tentative address by
       sending a Neighbor Advertisement (NA) message to the all-nodes
       multicast address on the AR->MN path as specified in ([RFC2461],
       Section 7.2.4).  If the NA message is lost, the MN will
       incorrectly assign the tentative address to an interface after
       RetransTimer msecs.

   3.  If a control message is lost on the AR<->MAP paths, the AR can
       assume loss after a timeout period and retry the registration
       until an acknowledgement is received.  If the retries are not
       completed within RetransTimer msecs and the address registration
       fails (due to address duplication or excessive retries), the MN
       will incorrectly assign the tentative address to an interface.

   One possible mitigation is for the MN to set DupAddrDetectTransmits
   (see: [RFC2462], Section 5.4) to some value greater than 1 at the
   expense of extra control message overhead and extra delay, but this
   mitigation can fail when more than DupAddrDetectTransmits control
   messages are lost.  A complementary mitigation is for the AR to set
   its retry timer to some value smaller than RetransTimer/N (where N is
   the desired number of retries) and/or for the MN to set RetransTimer
   to some value larger than the default of 1000 msecs.  But, since the
   MN<->AR<->MAP paths may be carried over links with arbitrarily-long
   delays, selecting appropriate timer values may be problematic in some
   use cases.  Also, this mitigation can fail when a NS/NA message is
   lost on the MN<->AR paths.

B.2.  Implications for Host-based Signaling

   In the DHCP-based MN-driven case specified in this document, if a
   control message is lost on the MN<->AR<->MAP paths, the MN will retry
   the DHCP request until a DHCP reply is received.  If excessive
   failures occur and the MN abandons its efforts, the DHCP server may
   have created useless address delegation state that will expire after
   the lease lifetime expires but the MN will not incorrectly assign an
   address to an interface.  The MN is also free to try again using
   different ARs which should lead to successful address registration
   and acknowledgement.

   DHCPv4 requests encode a Transaction ID ('xid') used by the client to
   match incoming messages with pending requests, and ([RFC2131],
   Section 4.1) states that: "Selecting a new 'xid' for each
   retransmission is an implementation decision.  A client may choose to
   reuse the same 'xid' or select a new 'xid' for each retransmitted
   message.".  DHCPv6 requests likewise encode a Transaction ID
   ('transaction-id'), but ([RFC3315], Section 15.1) states that: "A
   client MUST leave the transaction ID unchanged in retransmissions of
   a message.".

   So, for MNs that implement a DHCPv4 client that selects a new 'xid'
   for each retransmission, address registration may fail even after
   successive retries if the delay across the MN<->AR<->MAP paths is
   longer than the retransmission time.  For MNs that implement a
   DHCPv4/DHCPv6 client that uses the same Transaction ID for successive
   retries, address registration should succeed since any DHCP reply
   will complete the (retransmitted) DHCP request.

B.3.  Summary

   The network-based signaling mechanisms specified in [I-D.ietf-netlmm-
   mn-ar-if] leave opportunity for the MN to incorrectly assign an
   address to an interface, while the host-based signaling mechanisms
   specified in this document do not.  Therefore, applicability of the
   network-based model must be carefully analyzed for specific use cases
   and compared against MN complexity in the host-based method.

  

-----Original Message-----
From: Julien Laganier [mailto:[e-mail]] 
Sent: Tuesday, May 23, 2006 3:34 AM
To: [e-mail]
Cc: Templin, Fred L; Russert, Steven W; Chakeres, Ian D
Subject: Issue #22 (Was: Re: Issues #22 and #23)

On Thursday 11 May 2006 19:38, Templin, Fred L wrote:
> Repost to include dhc wg; comments to the list:

[ Not sure this is relevant to DHCWG list. Removed it. ]

> Some comments on resolutions for issues #22 and #23:
> > Issue #22: Multicast IPv6 ND triggers do not provide MN with
> > confirmation of MAP registration success/failure.
> > <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/22>
>
> Agree with cases 1) and 2), but there is also another case:
> 3) AR fails to reach the MAP due to packet loss caused by
> temporal congestion, signal intermittence, etc. In that
> case, the AR has to wait for a timeout period before either
> trying again or returning a false negative to the MN.
>
> If the AR takes too much time in retrying, the MN will
> wrongly conclude that its address has been registered with
> the MAP and its communications using that address will go
> into a black hole. 

I fail to see how the situation you describe is specific to NetLMM.

What if a plain host (not mobile, not in a NetLMM domain) selects an 
AR, but it happens that because of "packet loss caused by temporal 
congestion, signal intermittence, etc." that the IGP on that AR does 
not run properly preventing it to deliver packets...

It would send to the MN a ICMP destination unreachable and hopefully 
the MN would select another AR if there's one.

> If the AR returns a false negative (i.e., 
> a solicited NA), the MN will wrongly conclude that its
> proposed address is a duplicate. Neither of these anomalous
> conditions would occur if MAP registrations were driven by
> the MN itself instead of the AR, e.g., when the MN/AR/MAP
> are configured as DHCP client/server/relay.

I already expressed my opinion about DHCP: What if DHCP is not there? 
In the absence of DHCP, because our charter assume no host 
involvevement w.r.t. NetLMM how can the MN drive the MAP registration 
itself?

It sends a NS (as part of DAD) or a RS (as part of DNA). I said all of 
that already so I'll try to refrain from posting the same arguments 
again here. If anyone else has an opinion please speak up.

--julien

_______________________________________________
netlmm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/netlmm