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

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 May 2006 16:36:33 -0700

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
[email-masked]

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:[email-masked]] 
Sent: Tuesday, May 23, 2006 3:34 AM
To: [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Julien Laganier <[email-masked]>
Date: Wed, 31 May 2006 19:34:31 +0200

Fred,

[Sorry for the lag, I'm currently very busy]

Regarding your point on DHCP, the proposed resolution for issue #24 is 
to add text specifying how to integrate NetLMM and DHCP deployments. 
I did not have time yet to write down the actual text but I have 
already an idea of what I'm going to write (AFAICS there's no hard 
issue there.)

So we do not need to oppose a DHCP-based triggering of NetLMM to the 
ND-based one. I see them as complimentary. In a network using 
stateless autoconf ND is appropriate. *If* the deployment has DHCP 
I'm fine with it and the MN-AR interface will soon describe that.

Regarding the need for an applicability statement I don't have a 
strong opinion on that matter. I have the feeling that the people who 
will develop NetLMM implementations will understand enough the 
technology to apply it where necessary and documents their 
implementation/product so that end-users know where to use it best.

Best,

--julien

On Friday 26 May 2006 01:36, Templin, Fred L wrote:
>    [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:
>
>    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
>    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.
>
>    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.
>
>
>
> 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.
>
> 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 31 May 2006 14:15:42 -0700

Julien,

I see the point about complementary approaches and am OK with
the proposed resolution based on the text you produce. About
applicability, I would still like to see this group produce
something that will give an analysis of host-based and
network-based alternatives for various use cases but I guess
that would be outside the scope of the MN-AR interface spec?

Thanks - Fred

-----Original Message-----
From: Julien Laganier [mailto:[email-masked]] 
Sent: Wednesday, May 31, 2006 10:35 AM
To: Templin, Fred L
Cc: [email-masked]; Chakeres, Ian D
Subject: [netlmm] Re: Issue #22 (Was: Re: Issues #22 and #23)

Fred,

Best,

--julien